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What  Does  the  Future  Hold  for  Cloud  Computing? 

The  topic  of  cloud  computing  continues  to  generate  significant  interest 
among  information  technology  and  government  decision  makers  even  as  they 
hesitate  to  adopt  cloud  solutions  due  to  security  concerns. 
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Moving  to  the  cloud  is  the  latest  irresistible  force  to  sweep  the  C-suite  and  Main  Street. 
The  opportunities  for  flexibility,  savings,  reduced  sustainment,  and  ubiquity  have  made 
cloud  solutions  compelling  for  Information  Technology  (IT)  managers  around  the  world. 

Those  who  consider  the  benefits  of  cloud  computing  often  cite  potential  improve¬ 
ments  in  efficiency,  agility,  and  innovation.  These  individuals  often  indicate  that  existing 
computing  facilities  have  some  degree  of  duplication,  are  difficult  to  manage,  and  oper¬ 
ate  at  less  than  optimum  capacity.  A  major  benefit  of  the  cloud  would  be  the  ability  to 
rapidly  meet  new  demand  for  capacity  and  services  due  to  the  elastic  capacity  of  cloud 
providers.  Moreover,  the  cloud  also  reduces  the  need  for  asset  management  of  rapidly 
evolving  technology  and  enables  the  use  of  innovative  solutions. 

However,  there  are  security  challenges  unique  to  cloud  architectures,  including: 
dynamic  provisioning  of  platforms  of  unknown  or  dubious  origin,  global  access  by  mobile 
(and  largely  insecure)  devices,  eroded  trust  boundaries,  and  the  possibility  of  malevolent 
neighbors  in  your  public  cloud.  The  acquirer  of  services  must  be  aware  that  there  are 
variances  in  cloud  provider  security  capabilities.  Service  Level  Agreements  (SLAs)  pro¬ 
vide  important  coverage,  including  properly  articulated  security  and  resiliency  expecta¬ 
tions,  but  might  not  offer  a  comprehensive  solution. 

The  good  news  is  that  the  processes,  practices,  tools,  and  techniques  from  traditional 
IT  can  be  applied  to  address  many  cybersecurity  concerns.  As  savvy  consumers,  we  can 
employ  established  software  and  supply  chain  assurance  methods  when  acquiring  cloud- 
based  services,  as  long  as  we  recognize  the  new  risks  and  challenges  presented  by  this 
new  technology.  Cloud  computing  has  the  potential  to  improve  our  security  capabilities 
and  services.  As  agencies  and  departments  consider  various  cloud  architectures,  more 
stringent  security  requirements  will  encourage  cloud  service  providers  to  build  cloud 
services  with  significantly  improved  security. 

To  help  ensure  the  U.S.  Government  adopts  best  practice  methods  as  we  move  to 
the  cloud,  DHS  has  coordinated  with  NIST  and  other  federal  agencies  in  standardizing 
expectations  for  IT  security  for  cloud  services.  Moreover,  DHS  has  provided  technical 
assistance  to  the  Federal  Risk  and  Authorization  Management  Program  (FedRAMP). 
Housed  in  the  General  Services  Administration  (GSA),  the  FedRAMP  provides  a  security 
certification  and  authorization  process  that  applies  consistency  and  transparency  across 
Federal  departments  and  agencies  for  cloud  implementation  and  security.  This  program 
builds  security  into  the  government-wide  solicitations  from  the  beginning,  while  enabling 
agencies  to  retain  their  responsibility  and  authority  to  meet  their  unique  network  security 
needs.  For  providers,  the  FedRAMP  performs  oversight  of  continuous  monitoring,  and 
allows  vendors  to  participate  in  a  single  risk  management  process,  share  compatible 
requirements,  and  a  consistent  assessment  process. 

As  we  look  to  the  promise  of  FedRAMP  and  other  secure  services  delivering  capabili¬ 
ties  on  which  our  nation  depends,  our  cybersecurity  processes  and  procedures  will  con¬ 
tinue  to  evolve,  and  NIST  Special  Publications,  such  as  SP  800-53  “Security  and  Privacy 
Controls  for  Federal  Information  Systems  and  Organizations,”  will  remain  in  the  forefront 
of  security  guidance.  Although  there  will  always  be  more  to  be  done  to  achieve  a  safe 
and  cyber-secure  cloud,  we  must  embrace  a  shared  strategy  for  cybersecurity  and  work 
together  to  reap  the  benefits  we  all  envision  from  this  new  and  dynamic  technology. 


Roberta  “Bobbie”  Stempfley 

Acting  Assistant  Secretary 

Office  of  Cybersecurity  and  Communications 

Department  of  Homeland  Security 
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What  Does  the 
Future  Hold  for 
Cloud  Computing? 

David  Zage,  Sandia  National  Laboratories 
Dustin  Franklin,  Sandia  National  Laboratories 
Vincent  Urias,  Sandia  National  Laboratories 

Abstract.  The  topic  of  cloud  computing  continues  to  generate  significant  interest 
among  information  technology  and  government  decision  makers  even  as  they 
hesitate  to  adopt  cloud  solutions  due  to  security  concerns.  The  authors  define  the 
risks  associated  with  various  cloud  deployment  models  and  identify  key  solutions 
that  can  create  easy-to-use,  secure  cloud  deployments. 

1.  Introduction 

Even  though  recent  reports  have  begun  to  forecast  di¬ 
minished  interest  in  cloud  computing  [16],  large  numbers  of 
services  are  still  migrating  to  the  cloud  and  further  infrastructure 
is  being  dedicated  to  platforms  and  solutions.  While  a  large 
amount  of  cloud  research  has  focused  on  utilizing  the  power, 
flexibility,  and  potential  cost  savings  of  cloud  computing  plat¬ 
forms,  reports  such  as  the  Department  of  Homeland  Security 
Roadmap  for  Cybersecurity  Research  [9]  and  previous  research 
[4,  13]  have  expressed  the  explicit  need  for  continued  security 
analysis  of  cloud  computing  solutions.  In  polls,  over  70%  of 
government  decision-makers  [2]  and  80%  of  IT  executives  [3, 

1 4]  identify  security  and  ease  of  deployment  as  the  primary 
obstacles  to  cloud  computing  adoption. 
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•  Security/Privacy 

•  QoS  Guarantees 


Figure  1  -  Three  deployment  models  for  cloud  computing. 
General  descriptions  and  the  advantages  of  each  type  are 
listed  below  each  model. 


Cloud  services  deal  with  amounts  of  data,  users,  and  service 
heterogeneity  that  have  never  been  seen  before.  These  issues 
combine  with  the  desired  ubiquity  of  cloud  accessibility  to  create 
a  field  that  is  ripe  for  vulnerabilities  and  a  potential  playground 
for  adversaries.  There  has  been  work  towards  securing  cloud 
deployments,  but  security  is  still  typically  an  afterthought  as 
companies  focus  on  maintaining  service  availability.  Many  se¬ 
curity  solutions  are  ports  of  classic  paradigms  such  as  firewalls 
to  web  services.  These  ports  enhance  the  security  of  services 
running  on  the  cloud,  but  they  do  not  increase  the  intrinsic 
security  of  the  cloud  service  itself.  This  article  analyzes  the 
various  deficiencies  that  continue  to  hinder  cloud  deployments 
and  presents  three  key  areas  of  work  fundamental  to  improving 
cloud  services.  The  discussion  of  these  threats  and  solutions  is 
colored  by  the  authors  experience  in  creating  and  using  large- 
scale  cloud  infrastructures. 


Cloud  Deployment  Models 

In  the  field  of  cloud  computing,  three  cloud  deployment 
models  seen  in  Figure  1  have  emerged:  1)  public,  2)  private,  and 
3)  hybrid  clouds.  A  public  cloud  deployment  is  typified  by  the 
hardware  and  cloud  components  being  hosted  by  a  third  party 
provider  and  the  cloud  being  used  by  multiple  users.  A  user  has 
no  control  over  the  hardware  layer  and  varying  levels  of  control 
over  other  components  of  the  cloud  stack  seen  in  Figure  2. 
Public  cloud  deployments  were  developed  to  optimize  the  cost 
of  computation  and  storage  and  allow  massive  computing  jobs 
to  be  performed  for  a  fraction  of  their  former  costs.  This  cost 
savings  typically  comes  at  the  expense  of  security;  thus  causing 
increasing  interest  in  private  cloud  deployments.  Private  cloud 
deployments  are  owned  and  managed  by  a  single  organization. 
For  example,  a  company’s  IT  organization  may  choose  to  deploy 
a  Infrastructure-as-a-Service  (laaS)  cloud  usable  by  anyone  in 
the  company.  A  private  deployment  enables  the  owners  (e.g., 
corporate  IT)  and  users  to  have  control  over  the  full  stack  of 
cloud  system  components. 

The  next  logical  evolution  in 
cloud  deployments  leverages 
both  the  cost  savings  of  public 
clouds  and  the  potential  secu¬ 
rity  gains  of  private  clouds  by 
combining  them  into  a  hybrid 
cloud  service.  We  believe  this 
is  the  future  of  cloud  comput¬ 
ing,  but  will  highlight  issues 
that  must  be  taken  into  ac¬ 
count  before  deploying  a  hy¬ 
brid  cloud.  While  these  models 
are  designed  to  handle 
many  of  the  same  tasks  and 
thus  share  a  common  set  of 
threats,  there  are  also  security 
challenges  unique  to  each 
due  to  the  exposure  faced  by 
components  of  their  respec¬ 
tive  infrastructure.  We  now 
look  at  threats  common  to  all 
cloud  deployments. 
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Figure  2  -  The  operational 
stack  for  typical  cloud 
deployments. 
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2.  Common  Threats  to  Cloud  Computing 

The  utility  of  cloud  computing  must  be  weighed  against  the 
threats  it  faces,  which  fall  into  three  categories: 

a.  Failure  to  maintain  security 

b.  Loss  of  availability 

c.  Reduction  in  usability 

Security  issues  typically  result  from  an  adversary  attempting  to 
acquire  data,  knowledge,  or  persistent  access  to  a  system.  Losses 
in  availability  stem  from  an  adversary  trying  to  deny  legitimate 
user  access  to  a  cloud  for  the  purposes  of  annoyance,  delaying 
progress  of  work,  or  interfering  with  real-time  responses  to  critical 
situations.  Reductions  in  usability  can  affect  the  continued  viability 
of  a  cloud  service  and  the  cloud  paradigm  as  a  whole.  An  adver¬ 
sary  can  cause  systematic  faults  in  a  cloud  service  and  ultimately 
diminish  a  user’s  faith  in  that  cloud  service.  The  threats  affect  the 
three  deployment  models  universally  and  no  one  model  stands 
out  as  being  inherently  better  than  the  others. 

Failure  to  Maintain  Security 

Security  failures  are  the  most  conspicuous  threats  to  cloud 
computing.  Journalists  regularly  detail  significant  losses  of  data 
integrity  and  confidentiality  originating  from  targeted  attacks. 
Kapersky  Lab  reported  that  in  2013,  35%  of  businesses  have 
lost  data  due  to  flawed  system  security  [6].  The  widespread 
availability  of  internet  access  has  made  hacking  a  global  en¬ 
terprise,  allowing  adversaries  to  work  in  areas  where  they  face 
minimal  penalties  and  have  significant  incentives. 

Cloud  deployments  are  complex  systems  of  networked  com¬ 
ponents  that  must  work  seamlessly  in  order  to  secure  the  large 
amounts  of  information  they  contain.  A  single  misconfiguration 
or  an  unpatched  vulnerability  is  sufficient  to  lead  to  exploitable 
security  holes  and  allow  an  adversary  access  to  the  entire  in¬ 
frastructure.  For  example,  in  201  1 ,  Sony  Entertainment  was  the 
victim  of  a  series  of  attacks  on  various  pieces  of  their  infrastruc¬ 
ture  in  which  personal  information,  including  credit  card  informa¬ 
tion,  was  stolen  from  millions  of  accounts  [1 1].  Exact  details  of 
the  attack  vector  are  unpublished,  but  the  seriousness  of  the 
breach  became  apparent  when  the  attackers  released  stolen 
data  that  indicated  that  Sony  had  been  storing  user  information 
and  passwords  in  plain  text  [8].  For  their  lack  of  security  in  credit 
card  processing,  Sony  faced  many  repercussions,  including 
a  £250,000  fine  by  UK’s  Information  Commissioner’s  Office. 
Although  it  is  easy  to  blame  the  attackers,  companies  with  valu¬ 
able  information  need  to  be  cognizant  of  the  threats  they  face. 

Including  users  into  the  chain  of  trust  in  cloud  deployments 
has  caused  many  security  vulnerabilities.  Good  user  security 
practices  such  as  enforcing  strong  password  selection,  avoiding 
spearfishing,  and  testing  web  interfaces  for  cross  site  scripting 
attacks  are  necessary.  While  many  of  these  vulnerabilities  and 
practices  are  well  known,  it  is  important  to  make  note  of  them 
as  they  continue  to  impact  cloud  deployments. 

Loss  of  Availability 

No  matter  the  type  of  cloud,  a  user  wants  data  to  be  acces¬ 
sible  at  any  time  and  place.  Availability  is  reduced  as  networks 
and  machines  fail,  poorly  deployed  cloud  solutions  run  into 


bottlenecks,  and  cloud  services  face  distributed  denial  of  service 
(DDoS)  attacks.  This  is  a  particularly  pressing  issue  for  public 
clouds  as  they  provide  Service  Level  Agreements  (SLAs)  that 
are  based  on  their  contractual  ability  to  provide  computing 
power,  storage,  and  services.  Large  sums  of  money  stand  to  be 
lost  when  providers  fail  to  meet  their  SLAs. 

A  concern  that  bridges  both  security  and  availability  is  the 
capability  of  monitoring  the  state  of  data  during  its  lifetime  in  the 
cloud.  Problems  in  data  provenance  include  determining  if  data 
resides  in  locations  that  follow  the  same  regulations  a  business 
must  enforce  (e.g.,  HIPAA),  if  the  cloud  service  has  stored  the 
entirety  of  the  data,  if  the  data  remains  uncorrupted,  and  if  the 
data  is  truly  removed  once  it  has  been  deleted  by  the  user.  A 
user  that  uploads  his  or  her  data  to  a  third  party  may  be  forfeit¬ 
ing  inherent  rights  to  the  control  of  their  data,  which  could  then 
be  changed  or  viewed  without  notifying  the  user  [5].  While  this 
concern  may  appear  easier  to  manage  in  private  cloud  deploy¬ 
ments,  cloud  solutions  are  often  adopted  without  understand¬ 
ing  the  full  risk  profile.  IT  typically  lacks  the  tools  necessary  to 
understand  how  the  complex  pieces  fit  together  and  can  provide 
minimal  assurances  for  the  end-user  [1 4]. 

Reduction  in  Usability 

If  the  expected  performance  of  a  cloud  service  is  not  up  to  a 
user’s  expectations  or  its  SLA  guarantees,  the  user  may  change 
or  discontinue  usage.  Repeated  negative  experiences  result  in 
the  user  losing  faith  in  the  cloud  computing  paradigm.  Addition¬ 
ally,  corporations  desire  to  have  the  ability  to  quickly  deploy 
private  and  hybrid  clouds  with  minimal  effort  (e.g.,  testbed-as-a- 
service),  but  the  technology  for  doing  this  in  an  efficient,  repeat- 
able  manner  is  still  not  mature  enough  for  this  to  be  a  reality. 

3.  Threats  to  the  Different  Cloud  Deployment  Types 

Given  the  general  threats  discussed  in  Section  II,  this  section 
looks  at  cloud  deployment-specific  vulnerabilities. 

Public  Cloud  Deployments 

Common  to  all  public  cloud  systems  is  the  lack  of  control  over 
the  physical  storage  of  data.  In  clouds  which  give  the  user  mini¬ 
mal  access  to  the  cloud  stack,  such  as  software-as-a-service 
(SaaS)  clouds,  security  of  the  data  is  reliant  almost  entirely  on 
the  practices  used  by  the  cloud  provider,  over  which  the  user 
has  little  purview.  In  less  restrictive  systems,  such  as  laaS  clouds, 
users  are  allowed  to  create  and  deploy  virtual  machines,  which 
provide  greater  user  customization  and  control  of  data  storage. 
Several  cloud  service  providers  provide  preconfigured  virtual 
machines  for  their  users  to  minimize  user  effort  and  eliminate 
obvious  security  flaws. 

While  virtualization  is  a  great  enabling  technology,  there  have 
been  actual  attacks  demonstrated  where  a  virtual  machine 
can  be  compromised  and  used  to  bypass  system  protections, 
enabling  attacks  on  the  rest  of  the  cloud  infrastructure  [7,  1 8]. 
Although  cloud  providers  do  not  provide  information  on  other  cli¬ 
ents  running  on  the  same  physical  hardware,  adversarial  virtual 
machines  can  be  used  to  find  and  attack  specific  services  [1 5]. 

It  should  also  be  noted  that  cloud  providers  have  minimal  incen¬ 
tive  to  provide  secure  virtual  machines.  One  could  imagine  cases 
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in  which  unscrupulous  providers  may  distribute  virtual  machines 
containing  flaws  (e.g.,  networking  issues)  that  result  in  extra 
computation  and  network  usage,  simultaneously  earning  money 
for  the  provider  while  costing  the  customer. 

There  are  also  large  marketplaces  where  third-party  compa¬ 
nies  and  users  exchange  virtual  machines.  Users  need  to  be 
wary  of  these  virtual  machines  as  they  are  often  poorly  secured 
[12,  1],  These  preconfigured  solutions  have  been  found  to 
contain  unpatched  code,  share  credentials  with  other  virtual 
machines,  and,  worst  of  all,  even  Trojan  software.  Another  less 
obvious  problem  with  virtual  machines  that  users  must  be  aware 
of  is  they  often  lack  the  necessary  randomness  to  create  truly 
secure  cryptographic  keys,  especially  when  the  virtual  machines 
are  running  on  the  same  hardware. 

Users  of  public  clouds  may  suffer  from  attacks  that  are  not 
directed  at  them.  Any  network  outage  that  affects  the  cloud  will 
restrict  the  cloud  usability.  Clouds  regularly  face  DDoS  attacks 
attempting  to  bring  down  a  single  service  hosted  on  the  cloud. 
When  these  attacks  succeed,  they  have  the  side  effect  of  af¬ 
fecting  all  of  the  other  services  hosted  by  the  cloud  provider. 
Innocent  users  of  the  cloud  can  expect  that  a  successful  attack 
will  cause  downtime  for  their  services  even  though  they  are  not 
the  target.  One  potential  solution  to  dealing  with  such  issues  is 
through  the  use  of  hybrid  solutions,  enabling  at  least  partial  data 
access  even  during  downtime. 

Private  Cloud  Deployments 

The  primary  driver  behind  private  cloud  adoption  is  concern 
over  the  sensitivity  of  the  data  to  be  stored  and  processed.  Busi¬ 
nesses  desire  cloud  solutions  that  can  leverage  excess  internal 
capacity  while  minimizing  the  potential  for  data  leakage.  Addi¬ 
tionally,  internally  run  clouds  can  have  significant  advantages  in 
availability  and  accessibility  over  public  deployments. 

Many  companies  and  governmental  groups  are  constructing 
private  cloud  infrastructures  inside  their  network  perimeter.  This 
setup  can  often  be  easier  (and  more  comforting)  for  them  to  de¬ 
ploy  as  it  uses  many  traditional  system  security  mechanisms.  For 
example,  existing  web  security  (e.g.,  firewalls)  and  permission 
management  infrastructure  can  be  used  to  secure  the  system. 
While  these  mechanisms  provide  protection  from  outside  an 
organization,  they  are  not  configured  to  protect  resources  from 
mismanagement  and  malicious  insiders.  It  is  extremely  unlikely 
that  every  piece  of  data  should  be  available  to  every  department 
and  all  people.  Relying  entirely  on  access  control  at  the  network 
perimeter  can  lead  to  dissemination  of  data  to  an  adversary  that 
has  entered  the  network  through  another  route. 

Private  cloud  deployments  are  also  vulnerable  to  attacks 
designed  at  interrupting  availability,  such  as  DDoS  attacks. 

Public  cloud  providers  can  prepare  for  such  attacks  by  investing 
in  redundant  capacity  that  scales  to  handle  excessive  traffic  as 
needed.  A  private  cloud  will  not  have  the  same  growth  capability 
or  mitigation  techniques  and  the  system  may  fail  when  targeted, 
leading  to  unavailability  and  system  downtime. 

Ultimately,  the  security  of  a  private  cloud  depends  on  the  ca¬ 
pabilities  of  the  organization  deploying  it.  Currently,  the  deploy¬ 
ment  procedures  for  clouds  are  opaque,  with  multiple  services 
running  and  numerous  layers  of  abstraction  between  each  of 


the  services  and  between  the  services  and  their  administrative 
layers.  Often,  when  configuring  and  using  services  like  Open- 
Stack,  one  of  the  numerous  web  services  and  authentications 
will  fail  silently.  While  there  has  been  significant  work  done  by 
the  community  to  improve  the  deployment  and  administration 
of  tools  like  OpenStack  (such  as  using  common  configuration 
management/deployments  tools  like  Puppet),  there  are  really  no 
standard  solutions.  Differences  in  networks  (such  as  topology, 

IP  Space,  VLANs,  etc.),  in  hardware  (vendor,  raids,  etc.)  and 
underlying  virtualization  tools  all  provide  complexity  and  variation 
from  the  norm.  When  a  failure  does  occur,  determining  where 
the  failure  occurred  and  why  is  similar  to  finding  a  needle  in 
a  haystack.  Typically,  a  system  administrator  will  embark  on  a 
debugging  mission  that  might  result  in  a  functioning  system  or 
attempt  to  start  over  with  alternative  configurations.  Currently, 
there  are  no  tools  that  can  give  an  administrator  the  data  and 
insight  into  where/what  might  have  failed. 

Hybrid  Cloud  Deployments 

Hybrid  cloud  deployments  have  the  potential  to  offer  many 
of  the  positive  aspects  of  both  public  and  private  cloud  deploy¬ 
ments  in  a  single  service,  but  they  also  face  unique  challenges. 

A  primary  concern  is  understanding  the  composability  and  re¬ 
sulting  security  posture  of  the  hybrid  system.  Given  a  secure  pri¬ 
vate  and  public  cloud  deployment,  (provably)  aggregating  these 
together  to  create  a  secure  service  is  currently  an  open  problem. 
Most  hybrid  solutions  are  joined  by  easier-to-understand  higher 
level  protocols  (e.g.,  user  programs)  and  not  at  lower  levels  (e.g., 
a  cross-cloud  database).  Clearly  identifying  the  interfaces  and 
connectivity  patterns  between  the  public  and  private  compo¬ 
nents  is  a  critical  first  step  towards  creating  a  secure  service. 

Not  only  must  the  security  of  the  system  be  analyzed,  mitigation 
plans  for  availability  or  security  issues  affecting  either  portion  of 
the  cloud  must  be  in  place. 

Another  major  concern  not  present  in  other  deployment 
scenarios  is  the  accurate  disseminate  and  tracking  of  data 
between  the  multiple  components  of  the  cloud.  While  it  might  be 
attractive  to  use  the  private  portion  of  the  cloud  to  store  HIPAA 
data  and  the  public  for  non-sensitive  data,  it  must  be  ensured 
that  the  data  will  not  commingle.  Having  a  write-once,  read-only 
cloud  is  of  little  use. 

A  final  challenge  that  must  be  addressed  in  the  creation  of 
hybrid  solutions  is  configuration  management.  While  the  poten¬ 
tial  to  have  heterogeneous  solutions  is  beneficial  in  reducing  de¬ 
pendence  on  any  one  piece  of  software,  the  cloud  services  must 
be  easy  to  set  up.  This  necessitates  the  fusing  of  data  from  both 
the  public  and  private  cloud  to  create  a  common  interface  for 
deployment  and  management. 

4.  Enhancing  the  Security  of  Cloud  Deployments 

In  order  to  mitigate  some  of  the  security  issues  discussed, 
we  present  three  promising  solutions:  A)  enhanced  deployment 
techniques  that  are  automated  and  repeatable,  B)  full  stack 
cloud  introspection,  and  C)  enhanced  cloud  storage  solutions 
leveraging  multiple  providers.  Each  of  the  solutions  mitigates  a 
distinct  security  vulnerability  that  is  found  in  the  cloud  infra¬ 
structure.  They  can  provide  much  higher  levels  of  confidence 


6  CrossTalk-September/October  2013 


SECURING  THE  CLOUD 


in  the  security  posture  of  the  infrastructure  at  the  cost  of  some 
additional  management  challenges. 

Enhanced  Deployment 

If  an  organization  deploys  any  of  the  cloud  models  discussed 
previously  (e.g.,  a  private  cloud  for  internal  use  or  a  public  cloud 
for  commoditization  and  profit),  the  organization  must  understand 
how  to  construct  and  administer  the  entire  cloud  stack.  A  very 
basic  cloud  service  install  which  an  administrator  would  have  to 
create  might  resemble  Figure  3,  with  installation  occurring  from 
left  to  right.  Creating  such  a  procedure  is  difficult  and  must  be 
streamlined  and  instrumented  with  greater  amounts  of  under¬ 
standing/introspection  into  the  install  process.  Not  only  will  this 
enable  greater  cloud  adoption,  it  will  also  give  administrators 
the  ability  to  quickly  set  up  and  tear-down  cloud  deployments 
for  research  and  testing.  We  have  created  a  set  of  installers  for 
OpenStack  that  coalesce  an  immense  amount  of  logging  (from 
the  system,  network,  and  applications)  to  a  central  location.  We 
have  developed  tools  for  automated  install  analysis  as  well  as  a 
platform  to  begin  understanding  how  and  why  the  system  fails. 

Our  research  points  to  the  creation  of  a  deployment  pro¬ 
cess  resembling  object-oriented  design  patterns,  in  which  the 
interactions  and  required  functionality  between  each  phase  of 
the  install  are  predefined.  This  way,  a  component  in  any  step 
can  be  simply  exchanged  for  another  which  provides  the  desired 
functionality.  For  instance,  we  have  created  automated  install¬ 
ers  for  the  major  hypervisors  that  can  be  easily  interchanged. 

In  this  manner,  we  can  construct  standard  cloud  configurations 
and  take  the  uncertainties  out  of  deployment.  This  allows  for  the 
creation  of  standard  secure  builds  that  can  be  vetted,  tested, 
and  guaranteed  to  produce  repeatable  results.  Using  this  work, 
we  can  go  from  the  bare  metal  to  the  fully  operational  applica¬ 
tion  stack  that  can  be  re-provisioned  in  under  an  hour  on  tens  of 
different  hardware  variants. 


Figure  3  -  Example  cloud  installation  stack.  As  indicated  by  the  arrow,  the 
installation  process  flows  from  the  hardware  on  the  left  to  the  final  step  of 
setting  up  the  system  for  user  interaction  on  the  right. 


Figure  4  -  System 
diagram  of  a  full 
cloud  analysis 
solution  lever¬ 
aging  security 
information  and 
event  manage¬ 
ment  solutions. 


Cloud  Analysis 

While  clouds  are  complex,  one  of  the  potential  advantages 
of  cloud-based  computing  is  that  it  opens  the  possibility  of  un¬ 
derstanding  the  entire  infrastructure.  This  understanding  comes 
down  to  intelligently  gathering  and  processing  a  myriad  of  sys¬ 
tem  packets  and  logs.  Each  component  of  the  cloud  stack,  from 
the  bare  metal  operating  system,  to  the  virtual  machine  man¬ 
ager,  to  the  application  being  hosted  by  the  virtual  machine  syn¬ 
thesizes  logs  that  need  to  be  analyzed.  If  this  flood  of  informa¬ 
tion  can  be  efficiently  aggregated  and  correlated,  this  enables 
an  administrator  to  understand  the  context  of  the  applications, 
develop  situational  awareness,  and  leverage  this  awareness  for 
detection  and  prevention.  One  potential  avenue  currently  being 
explored  for  creating  analyzable  cloud  infrastructure  is  by  instru¬ 
menting  logs  in  each  level  of  the  system  and  capturing  them  in 
a  security  information  and  event  management  (SI EM)  solution 
such  as  Splunk.  The  SIEM  solution  will  interrogate  each  service 
and  aggregate  the  information,  allowing  for  easy  visualization  of 
data  and  trends.  Figure  4  is  an  example  of  the  analysis  frame¬ 
work  we  are  investigating.  With  this  framework,  we  have  been 
able  to  quickly  triage  hardware  and  application  failures  as  well 
as  provide  a  record  of  the  events  on  the  system. 


Figure  5  -  The  security  of  the  cloud  service  should  render  the  cloud 
usable  to  a  legitimate  user  even  when  under  attack. 
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While  a  common  log  area  and  visualizations  are  of  great  utility 
to  an  administrator,  these  are  only  a  first  step  to  better  under¬ 
stand  a  cloud.  Automated  analysis  techniques  such  as  outlier 
identification  and  (un)supervised  machine  learning  techniques 
can  be  built  on  top  of  this  data,  allowing  for  near  real-time,  less 
manually  intensive  identification  of  problems  and  security  con¬ 
cerns.  Also,  much  of  this  information  would  be  useful  to  the  end- 
user  of  the  cloud.  A  critical  research  challenge  for  the  future  is 
enabling  an  end-user  to  leverage  these  logs  in  a  secure  manner. 
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Improved  Cloud  Storage 

The  third  area  we  see  as  critical  to  the  continued  success  of 
cloud  computing  is  the  continued  development  of  improved  data 
storage  protocols.  The  concept  of  the  cloud  has  been  great  for 
monetizing  computing  capabilities  and  a  provider’s  return  on 
investment  has  been  tightly  coupled  with  availability.  This  has 
typically  left  security  as  an  afterthought  or  the  burden  has  been 
placed  on  the  user  to  ensure  the  confidentiality  and  integrity  of 
their  data.  As  seen  in  Figure  5,  users  need  storage  solutions 
that  can  seamlessly  integrate  multiple  heterogeneous  storage 
services  (e.g.,  a  local  cloud  storage  service  and  Amazon  S3) 
while  providing  the  security  the  user  needs  and  expects.  Even 
with  the  system  under  attack,  the  user  should  be  able  to  experi¬ 
ence  it  as  if  the  environment  was  benign. 

One  of  the  areas  we  are  currently  exploring  is  the  use  of 
wheat  and  chaff  (W&C)  storage.  W&C  uses  multiple  algebraic 
operations  of  linear  subspaces  to  encode  and  replicate  data.  By 
encoding  data  in  large  finite  fields,  we  create  solutions  which 
offer  the  end-user  provable  data  confidentiality  and  integrity  and 
provide  lightweight  checks  on  the  user’s  data-related  service  level 
agreement.  As  part  of  this  research,  a  completely  non-preferential 
dynamic  partitioning  system  was  developed  utilizing  online  codes 
[1 0]  that  allows  for  maximal  robustness  when  splitting  data 
between  multiple  cloud  providers.  This  total  system  can  provide 
the  end-user  with  informed  trade-offs  between  cost,  performance, 
and  security.  This  functionality  is  critical  for  the  continued  growth 
of  hybrid  solutions.  For  more  information,  see  [1 7]. 

5.  Looking  Towards  Continued  Adoption 

We  believe  the  future  of  cloud  computing  rests  in  the  op¬ 
portunities  and  challenges  present  in  hybrid  cloud  deployments. 
These  allow  organizations  to  have  better  resiliency  to  failure, 
establish  data  models  for  multiple  types  of  data  (i.e.,  increased 
privacy  for  data  that  remains  in  a  private  infrastructure),  and  op¬ 
timize  cost  and  resource  usage  by  utilizing  the  appropriate  cloud 
offerings.  The  solutions  we  present  and  continued  work  in  the 
areas  of  creating  automated  cloud  deployments,  improved  full 
cloud  management,  and  secure  storage  will  mitigate  new  cloud 
challenges  before  they  become  problematic. 
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The  Art  of  Cyber 
Bank  Robbery 

Stealing  Your  Money  Through 
Insidious  Attacks 

Aditya  K.  Sood,  Michigan  State  University 
Richard  J.  Enbody,  Michigan  State  University 

Abstract.  Cyber  criminals  are  using  advanced  attacks  to  exploit  online  banking 
systems  and  services  to  covertly  steal  money.  This  paper  describes  the  tactics  cur¬ 
rently  used  by  cyber  criminals  to  conduct  cyber  bank  robbery. 

Introduction 

Cyber  criminals  use  botnets  (malware)  for  a  wide  range  of 
cyber  crimes,  and  these  attacks  are  increasing.  The  econom¬ 
ics  of  e-crime  and  the  related  underground  market  have  been 
studied  which  reveal  a  significant  increase  in  online  fraud  [1]. 
Internet  banking  (e-banking)  has  transformed  the  economic 
and  financial  culture  of  the  world.  Over  time,  banks  have 
strengthened  the  security  of  their  servers  to  the  point  that 
attackers  now  target  end-user  systems.  Server-side  defenses 
are  easier  for  banks  because  the  banks  have  control  over 
their  servers.  As  client  computers  are  outside  of  the  banks’ 
control,  this  makes  it  harder  for  the  banks  to  subvert  insidi¬ 
ous  attacks  conducted  on  end-user  systems.  Due  to  this  rea¬ 
son,  Internet-based  threats  are  posing  security  challenges  to 
online  banking.  Given  the  increasing  sophistication  of  attacks 
on  the  client  side,  it  is  imperative  to  build  robust  protection 
mechanisms  on  the  client  side  that  can  be  managed  from  the 
server  side. 

Necessity  is  the  mother  of  invention.  This  aphorism  applies 
to  the  current  creativity  of  cyber  criminals.  Ever  more  sophis¬ 
ticated  defenses  have  spurred  attackers  to  develop  more  ad¬ 
vanced  attacks.  The  resulting  innovative  system-exploitation 
tactics  exfiltrate  data  from  infected  clients  around  the  world. 
The  web  browser  is  the  primary  user  interface  to  the  Internet 
and  thus  is  a  centralized  target  for  attacks.  The  attackers  de¬ 
sign  sophisticated  client  side  malicious  code  that  subverts  a 
browser’s  functionality  to  harvest  credentials  and  to  perform 
money  transfers  on-the-fly  in  a  hidden  manner.  The  fact  that 
these  attacks  are  designed  and  structured  around  browsers 
shows  how  critical  it  has  become  to  secure  browser  software. 

Today,  the  most  common  platform  for  broad  attacks  on 
banking  is  via  botnets.  Those  attacks  are  causing  significant 
losses  both  in  fraud  and  in  defensive  costs.  Selling  and  rent¬ 
ing  botnet  frameworks  are  an  integral  part  of  the  under¬ 
ground  economy’s  revenue  model.  Hundreds  of  millions  of 
dollars  are  earned  by  cyber  criminals,  and  billions  of  dollars 
are  expended  keeping  those  losses  in  check. 

In  2009,  Cormac  and  Dinei  [2]  conducted  a  study  on  the 
economics  of  the  underground  economy  and  estimated  that 
a  botnet  herder  earns  approximately  $0.50  per  machine  per 
year.  For  a  botnet  of  50,000  machines,  a  botnet  herder  could 


earn  approximately  $25,000.  Recent  botnets  such  as  Zeus, 
SpyEye,  and  Citadel  have  infected  millions  of  machines.  If  the 
same  formula  is  applied,  potential  earnings  are  in  millions  of 
dollars  every  year.  Some  income  comes  from  renting  out  the 
infected  machines,  but  there  are  also  Pay  Per  Infection  (PPI) 
services  where  bot  herders  charge  customers  to  distribute 
malware  for  a  fee  across  their  botnet.  PPI  rates  vary  signifi¬ 
cantly  depending  on  where  targeted  machines  are  located. 

For  example,  $  1 30  to  $  1  50  is  charged  per  1 ,000  machines 
to  load  malware  on  computers  located  in  the  U.S.,  but  the 
rate  is  as  low  as  $3  to  $5  for  locations  in  Asian  countries 
such  as  China.  In  either  case,  providers  of  PPI  services  can 
earn  millions  of  dollars  annually. 

On  the  defensive  side,  Anderson  et  al.  in  their  study  of 
cyber  crime  [3]  pointed  out  that  botnet  mitigations  cost  $ 

3.2  billion  for  anti-virus  software  alone.  Globally,  the  study 
estimated  that  companies  spend  roughly  $10  billion  annually 
to  provide  defenses  against  cyber  crimes.  In  addition,  they 
projected  that  total  global  law  enforcement  expenditures 
were  approximately  $400  million  for  cyber  crime.  The  study 
also  concluded  that  global  online  banking  fraud  losses  were 
close  to  $300  million,  and  to  prevent  additional  frauds,  banks 
spent  approximately  $1  billion.  Florencio  and  Herley  of  Micro¬ 
soft  Research  [21]  found  that  credentials  are  offered  in  the 
underground  market  at  $0.05  on  the  dollar  value  of  the  ac¬ 
count.  It  leads  them  to  observe  that  converting  credentials  to 
cash  is  the  hard  part  and  only  a  few  stolen  credentials  result 
in  actual  theft.  They  analyze  that  the  biggest  cost  comes  from 
defensive  costs  and  Anderson’s  data  supports  that  conclu¬ 
sion. 

In  this  paper,  we  present  the  cyber  bank  robbery  model 
that  is  used  by  cyber  criminals  to  conduct  online  frauds  using 
automated  exploitation  frameworks  such  as  botnets.  This 
model  is  used  for  attacking  end-user  systems  and  mobile 
platforms. 

Overview  and  Threat  Model 

Skilled  cyber  criminals  are  responsible  for  the  majority  of 
online  bank  fraud.  The  attack  process  can  be  outlined  as 
follows: 

•  Infection  Entry  Point  and  Exploitation:  A  cyber  crimi¬ 
nal  begins  by  co-opting  a  high-volume  website  to  host  an 
automated  exploitation  framework.  That  framework  exploits 
browsers  having  vulnerable  components  using  what  is  known 
as  a  drive-by  download.  The  users  are  coerced  to  visit  the  in¬ 
fected  website  using  techniques  such  as  phishing.  In  addition, 
malicious  applications  can  also  be  installed  on  mobile  devices 
to  control  communication. 

•  Data  Exfiltration  A  bot  is  installed  on  the  infected 
system  that  connects  back  to  a  C&C  computer.  For  example, 
if  the  cyber  criminal  wants  to  attack  Bank  of  America  (BofA) 
sessions,  it  commands  the  bot  to  download  the  appropriate 
plugin.  The  bot  hijacks  (hooks)  the  communication  chan¬ 
nel  initiated  by  the  browser  with  the  BofA  website  to  steal 
account  information,  credentials,  registered  email  addresses, 
etc.  The  key  point  is  that  the  attack  exploits  client-side  soft¬ 
ware,  the  browser  in  particular.  Apart  from  that,  the  bots  can 
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simply  send  phishing  emails  that  exploit  brand  reputation  of 
online  websites  and  trick  users  to  provide  sensitive  informa¬ 
tion.  In  mobile  devices,  apart  from  HTTP,  SMS  is  used  as  a 
carrier  for  exfiltrating  data. 

•  Fraud:  Once  the  data  is  exfiltrated  from  the  user  ma¬ 
chine,  cyber  criminals  either  sell  it  in  the  underground  com¬ 
munity  or  use  it  themselves.  In  advanced  attacks,  malicious 
code  can  execute  fraudulent  transactions  directly  from  the 
infected  systems.  All  these  features  depend  on  the  design  of 
bots. 

This  paper  presents  a  model  of  cyber  bank  robbery  struc¬ 
tured  into  four  phases.  Phase  1  describes  malware  design. 
Phase  2  presents  strategies  to  get  malware  onto  users’  com¬ 
puters  and  mobile  devices.  Phase  3  chronicles  the  exfiltration 
of  sensitive  data  and  automated  transactions.  Phase  4  covers 
the  transformation  of  data  to  money.  To  conclude,  we  discuss 
different  security  mechanisms  deployed  by  banks  to  combat 
online  fraud  and  their  shortcomings. 

We  use  the  following  terminology:  malware  refers  to  any 
malicious  code  that  modifies  the  behavior  of  target  compo¬ 
nents.  A  bot  is  an  automated  malware  that  communicates 
with  a  remote  server  and  performs  multiple  tasks  in  an 
infected  system  in  a  stealthy  manner. 

1.  Phase  1:  Malware  Design 

Botnets  play  a  critical  role  in  widespread  infections  on  the 
Internet.  A  botnet  is  a  network  of  compromised  machines 
that  are  infected  with  bots.  Bots  steal  sensitive  information 
such  as  banking  credentials  from  target  users  and  have  the 
ability  to  perform  other  nefarious  tasks.  The  bots  are  sophis¬ 
ticated  and  implement  advanced  techniques  to  bypass  anti¬ 
virus  engines  and  other  host-based  protection  software  [4]. 

Present-day  bots  have  the  capability  to  co-opt  the  commu¬ 
nication  flow  in  browsers  through  Man-in-the-Browser  (MitB) 
attacks.  These  attacks  enable  the  bots  to  harvest  credentials 
using  techniques  such  as  form  grabbing  and  web  injects 
(explained  later  in  this  paper).  In  addition,  the  MitB  attack 
allows  the  bots  to  make  automated  fraudulent  transactions 
by  exploiting  the  active  session  with  the  banks.  Because 
these  attacks  are  executed  from  the  infected  system,  they 
are  mostly  hidden  from  the  banks.  MitB  functionality  has 
revolutionized  the  design  of  third-generation  botnets.  Since 
a  browser  is  a  user’s  window  to  the  Internet,  it  is  the  target 
of  attackers:  controlling  the  browser  controls  the  interac¬ 
tion.  As  operating  systems  have  become  hardened,  attackers 
find  attacking  applications  such  as  browsers  to  be  easier.  A 
detailed  browser-malware  taxonomy  [5]  exists  that  discusses 
the  various  classes  of  browser-based  malware.  Understand¬ 
ing  browser-based  malware  is  necessary  to  comprehend 
the  strategies  opted  by  malware  authors  to  conduct  stealthy 
attacks  on  the  end  user  systems. 

On  similar  benchmark,  Man-in-the-Mobile  (MitMo)  attacks 
are  conducted  in  mobile  devices  to  manipulate  and  hijack 
the  functionalities  of  installed  applications.  In  these  attacks, 
malicious  applications  use  a  camouflaging  trick  to  hide  their 
identity  and  trick  users  to  believe  them  as  authentic  ones. 

The  cyber  criminals  are  designing  malicious  code  for  com¬ 


puter  systems  as  well  as  mobile  platforms.  The  most  promi¬ 
nent  malware  designs  that  are  used  in  online  banking  frauds 
are  discussed  next. 

1.1  Man-in-the-Browser  (MitB)  Agents 

The  evolution  of  MitB  [6]  attacks  has  given  birth  to 
advanced  client-side  attacks.  MitB  attacks  are  similar  to  Man- 
in-the-Middle  (MitM)  attacks,  but  exist  within  the  operating 
systems  to  exploit  browsers.  MitB  agents  can  be  thought  of 
as  userland  rootkits  that  subvert  the  integrity  of  browsers  by 
hooking  [7]  selective  Dynamic  Link  Libraries  (DLL)  to  control 
the  execution  flow  of  various  browser  functions.  When  the 
browser  calls  a  communication  function,  the  hook  diverts 
control  to  malicious  code.  This  approach  allows  cyber  crimi¬ 
nals  to  conduct  stealth  attacks  by  manipulating  the  communi¬ 
cation  channel  between  browsers  and  the  remote  servers. 

Hooking  is  an  integral  to  many  operating  systems  and  is 
used  frequently  in  Windows.  In  the  context  of  browser  ex¬ 
ploits,  hooking  allows  running  processes  to  alter  the  behavior 
of  various  components  in  the  system  by  intercepting  the  in¬ 
terprocess  communication  channel.  The  latest  bots  use  inline 
function  hooking  [8]  which  is  hard  to  detect  because  it  uses 
hot  patching  and  late  binding,  that  is,  the  hook  is  actually 
executed  during  runtime.  MitB  agents  are  capable  of  stealing 
data,  manipulating  content  and  automating  the  critical  opera¬ 
tions  without  the  intervention  of  users.  Web  injects  and  form 
grabbing  are  the  two  most  widely  used  MitB  techniques  that 
implement  hooking  to  control  browser  operations.  These  are 
discussed  in  the  next  sections. 

1.2  Browser  Rootkits 

Browser  rootkits  [9]  are  defined  as  advanced  levels  of 
malware  that  hide  inside  browsers  and  perform  unauthor¬ 
ized  operations  without  users’  knowledge.  The  concept  of 
a  browser  rootkit  originated  from  system  rootkits  that  are 
capable  of  hiding  and  covertly  interacting  with  the  system 
components.  Browser  rootkits  are  malicious  extensions  (add 
ons)  that  use  JavaScript  to  manipulate  the  content  of  web 
pages.  In  addition,  browser  rootkits  can  easily  alter  the  look 
and  feel  of  the  web  pages  to  fool  users  and  trick  them  into 
performing  illegitimate  operations.  These  are  also  capable  of 
altering  information  [10]  in  active  sessions,  account  profiles, 
online  transactions,  etc.  after  the  user  successfully  authenti¬ 
cates  to  an  online  banking  website.  The  browser  rootkits  are 
primarily  designed  to  execute  fraudulent  transactions  when  a 
user  activates  a  session  with  an  end  server. 

1.3  Man-in-the-Mobile  (MitMo)  Agents 

With  the  advent  of  mobile  technologies,  cyber  criminals 
have  started  targeting  smart  phones.  Mobile  platforms  such 
as  Android  have  been  the  target  of  cyber  criminals.  In  the 
last  few  years,  a  number  of  mobile-based  botnets  have  been 
revealed  that  subverted  the  integrity  of  mobile  platforms  to 
conduct  attacks  and  exfiltrate  sensitive  information.  For  ex¬ 
ample:  the  existence  of  mobile  variants  of  Zeus  and  SpyEye 
i.e.  Zitmo  and  Spitmo  [25]  respectively  show  that  the  design 
of  botnets  is  evolving  with  new  technologies.  Mobile  botnets 
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[26]  are  similar  to  standard  botnets  but  they  aim  specifi¬ 
cally  to  exploit  mobile  architectures.  Mobile  bots  are  termed 
as  MitMo  agents  that  are  malicious  applications  installed  to 
thwart  the  security  model  of  the  mobile  device  and  exfiltrate 
data  accordingly.  These  are  designed  to  control  the  com¬ 
munication  channel  initiated  by  legitimate  applications  with 
legitimate  servers  in  a  stealthy  manner. 

Malicious  mobile  applications  work  in  conjunction  with 
traditional  botnets  to  subvert  the  multi  channel  protection 
mechanisms  such  as  two-factor  authentication  (TFA)  [29]. 
Malicious  applications  are  designed  to  conduct  piggybacking 
attacks  [27]  to  monitor  the  state  of  target  application  (such 
as  banks)  and  stealing  information  during  transmission.  Fake 
applications  can  also  be  forced  to  be  installed  on  mobile 
devices  that  trick  the  users  to  provide  sensitive  information. 
On  Android  [30],  apart  from  exploiting  vulnerabilities,  malware 
authors  use  infection  techniques  such  as  stealthy  assets,  in¬ 
fected  boot  images,  time  specific  code  execution,  etc.  to  hide 
malicious  codes.  Android  being  open  source  is  the  preferred 
choice  of  cyber  criminals.  Because  Blackberry  and  Apple  use 
closed  source  operating  systems,  the  ratio  of  mobile  malware 
attacking  these  platforms  is  less  than  on  Android. 

1.4  Automated  Phishing  Bots 

Apart  from  browser-based  exploitation,  bots  are  also 
designed  to  trigger  phishing  attacks.  End  users  are  tricked  to 
visit  illegitimate  domains  hosting  fake  web  pages  that  appear 
similar  to  legitimate  bank  sites.  Bots  can  send  thousands 
of  phishing  emails  at  a  time  to  a  large  set  of  users  on  the 
Internet.  Honeynet  [22]  talks  about  how  bots  can  be  used  to 
send  phishing  emails  directly  from  infected  computers  and 
also  from  C&C  panels.  The  phishing  attacks  are  not  new  and 
have  been  in  existence  for  years.  But,  the  amazing  part  is 
that  these  attacks  still  exist  and  play  a  significant  role  in  data 
exfiltration  today.  No  stealthy  technique  is  deployed  during 
these  attacks  because  phishing  is  based  on  social  engineer¬ 
ing  to  exploit  the  trust  and  knowledge  of  users.  Botnets  such 
as  Grum  and  Festi  [24]  are  specifically  designed  for  conduct¬ 
ing  phishing  attacks  including  spamming.  On  the  contrary, 
Spamhaus  [23]  is  an  effort  that  is  used  to  track  botnets  that 
send  spam. 

2.  Phase  2:  Malware  Distribution 

The  following  section  is  an  examination  of  tactics  chosen 
by  cyber  criminals  to  widely  infect  systems.  Broad-based  at¬ 
tacks  (mass  infections)  have  evolved  over  time  and  currently 
a  popular  technique  is  to  drive  victims  to  websites  where  they 
will  be  served  malware  or  redirected  to  sites  that  serve  mal¬ 
ware.  A  target  website  is  often  a  legitimate  website  that  has 
been  corrupted  (e.g.,  injected  with  a  malicious  iframe)  to  send 
visitors  to  a  malicious  site.  Some  of  the  most-widely  used 
malware  distribution  strategies  are  discussed  below: 

•  Phishing  is  used  to  drive  users  to  sites  hosting  a  drive- 
by  download  attack  [1  1].  A  drive-by  download  attack  silently 
exploits  vulnerabilities  in  browser  components  to  download 
malware  without  user  action.  This  malware  is  capable  of 
executing  MitB  attacks  to  perform  fraudulent  transactions 


and  data  exfiltration  from  the  infected  system.  To  automate 
the  exploitation,  cyber  criminals  have  designed  Browser 
Exploit  Packs  (BEPs)  such  as  BlackHole.  A  browser  exploit 
pack  fingerprints  the  user’s  browser  to  identify  vulnerabilities 
and  then  load  the  appropriate  exploit.  BEPs  are  sold  as  a 
crimeware  service  that  charges  buyers  using  a  PPI  model  as 
discussed  earlier. 

•  The  popularity  of  Online  Social  Networks  (OSNs)  makes 
them  attractive  targets  for  attackers  to  distribute  malware 

by  exploiting  trust  among  users.  The  attackers  use  the 
social  network  platforms  and  trust  among  “friends”  to  direct 
“friends”  to  malicious  websites.  For  example,  Likejacking  at¬ 
tacks  cause  users  to  inadvertently  “like”  a  malicious  site  that 
tricks  a  user  to  download  malware. 

•  Bots  are  also  distributed  in  traditional  ways  such  as  in 
warez  or  freeware  that  are  downloaded  from  the  illegitimate 
websites  on  the  Internet  carrying  malware.  Also,  fake  anti¬ 
virus  and  other  phony  tools  are  still  used  to  trick  users  to 
download  malicious  code. 

•  Bots  have  a  built-in  functionality  of  spreading  using 
which  they  infect  peripheral  devices  such  as  USBs  to  trans¬ 
mit  themselves  to  different  machines.  In  addition,  spreaders 
can  also  infect  Instant  Messaging  (IM)  software  and  OSNs. 

•  Mobile  bots  and  malicious  applications  are  distributed 
as  repackaged  applications  that  mean  the  malicious  code  is 
hidden  inside  a  legitimate  application.  The  repackaged  ap¬ 
plications  are  distributed  on  alternate  markets.  Existence  of 
vulnerabilities  present  in  legitimate  market  stores  also  allows 
the  attackers  to  host  malicious  applications.  Other  carriers 
include  Over-the-Air  (OTA)  installation,  mobile  malvertising, 
etc. 

Together  these  methods  are  sufficiently  effective  in  distrib¬ 
uting  bots.  The  resulting  zombie  machines  (infected  systems) 
are  managed  remotely  through  a  centralized  C&C  server  that 
is  owned  and  operated  by  a  botmaster  (or  bot  herder).  Once 
a  cyber  criminal  has  controlled  a  set  of  infected  computers, 
the  next  step  in  financial  fraud  is  to  collect  credentials  or 
conduct  automated  transactions. 

3.  Phase  3:  Data  Exfiltration  and 
Stealthy  Operations 

Data  exfiltration  refers  to  transferring  sensitive  data  from 
an  infected  machine  to  a  remote  C&C  server.  Multiple  tech¬ 
niques  exist;  the  most  widely  deployed  data  exfiltration  and 
automated  injection  techniques  used  by  banking  malware  are 
discussed  below. 

3.1  Form  grabbing  and  Keylogging 

Form  grabbing  is  an  impressive  technique  for  extracting 
data  present  in  web  forms.  This  technique  is  more  advanced 
than  keylogging— a  tool  that  results  in  a  lot  of  irrelevant  data 
that  must  be  sifted  through  to  find  desired  information  such 
as  credentials.  In  contrast,  form  grabbing  grabs  only  the 
HTTP  Post  data  sent  as  a  part  of  form  submission  request.  In 
particular,  form  grabbing  greatly  simplifies  and  automates  the 
extraction  of  banking  credentials  making  this  process  avail¬ 
able  for  the  less  sophisticated  criminal.  However,  with  recent 
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botnets  such  as  Citadel,  both  keylogging  and  form  grabbing 
techniques  are  deployed  for  assurance  purposes. 

Form  grabbing  works  on  forms  that  users  fill  out  and  sub¬ 
mit  to  a  bank— especially  forms  used  for  logging  and  online 
transactions.  As  the  browser  is  already  hooked  (MitB),  a  bot 
agent  can  easily  snoop  the  communication  channel  between 
the  client  and  the  server.  As  soon  as  the  user  submits  the 
form,  the  bot  agent  extracts  the  data  present  in  the  forms, 
generates  a  socket  in  the  system  and  transmits  the  data  back 
to  a  C&C  server.  Data  in  all  the  HTTP  POST  requests  can  be 
exfiltrated  from  the  system  without  a  user’s  knowledge  [12]. 


set_url  https://www.wellsfargo.com/*  G 
data_before 

<span  class="mozcloak"xinput  type="password"*</span> 

data_end 

datajnject 

cbrxstrongxlabel  for="atmpin">ATM  PIN</label>:</strong>&nbsp;<br  /> 

<span  class="mozcloak"xinputtype="password"  accesskey="A"  id="atmpin"  name="USpass" 

size="13"  maxlength="14"  style="width:147px"  tabindex="2"  /></span> 

data_end 

data_after 

data_end 

Listing  1  -  Wl  rule  written  against  Wells  Fargo  Bank 

3.2  Web  Injects 

Web  Injects  (Wl)  is  an  advanced  technique  of  content  in¬ 
jection.  When  a  user  submits  a  form  and  waits  for  a  response 
from  a  web  server,  a  bot  agent  is  activated  and  starts  inject¬ 
ing  illegitimate  content  into  the  incoming  HTTP  responses. 
This  process  tricks  the  user  into  believing  the  web  server  has 
sent  all  of  the  content.  Wl  is  effective  in  coercing  users  to 
provide  information  that  is  otherwise  not  easy  to  attain.  For 
example,  an  attacker  could  request  a  PIN,  a  Social  Security 
number,  or  a  second-channel  SMS  number.  This  attack  is  a 
variant  of  a  MitB  attack  because  it  hooks  various  read/write 
functions  in  browser  libraries  to  inject  data.  This  technique  is 
implemented  as  follows: 

•  Cyber  criminals  have  to  design  specific  rules  for  a  bot 
agent  to  perform  Wl.  A  bot  agent  reads  various  rules  from 
a  static  file  and  then  uses  hooking  to  apply  those  rules  to 
modify  incoming  HTTP  responses.  Rules  are  tied  to  specific 
web  pages,  e.g.,  the  login  page  of  a  bank. 

•  It  is  crucial  that  the  rules  are  structured  properly  be¬ 
cause  inappropriate  Wl  rules  can  seriously  disrupt  the  web 
page  layout  and  the  dynamic  execution  of  JavaScripts.  Wild 
modification  of  the  web  stream  will  be  obvious  and  hence 
ineffective.  For  successful  Wl,  the  injected  content  has  to 
work  inline  without  any  display  of  errors  or  notifications  to  the 
users. 

•  Cyber  criminals  are  required  to  define  several  param¬ 
eters  to  write  different  Wl  rules.  The  Wl  rules  are  written 
explicitly  for  every  GET  and  POST  request  with  a  dedicated 
URL.  There  are  two  specific  parts  of  the  Wl  rule.  First,  it  is 
required  to  define  the  target  URL  (bank  website,  etc.)  whose 
content  is  to  be  hooked  and  modified.  Second,  in  every  rule 

it  is  required  to  define  the  layout  of  the  web  pages,  e.g. 
specify  a  portion  of  the  webpage  in  which  the  content  is  to 
be  injected  in  order  to  render  the  content  appropriately  in  the 
browser. 
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Listing  1  shows  a  Wl  rule  extracted  from  an  infected 
machine.  The  rule  injects  additional  input  asking  for  a  user’s 
ATM  PIN.  It  is  an  unusual  request  from  a  bank,  but  since  the 
page  is  otherwise  legitimate,  trust  compels  a  user  to  enter 
the  information.  This  injection  is  placed  before  the  password 
input  box  (specified  by  the  data_before  tag)— injecting  inline 
as  the  web  page  enters  the  browser.  The  details  of  the  pa¬ 
rameters  used  to  write  a  Wl  rule  are  discussed  in  [13].  As  Wl 
is  a  problem  at  the  client  side,  banks  currently  have  no  robust 
protection  against  this  attack.  In  addition,  cyber  criminals  can 
inject  sophisticated  JavaScripts  to  perform  online  transac¬ 
tions  automatically.  For  example,  a  bot  injects  malicious 
JavaScript  during  an  active  session  with  the  server.  The 
JavaScript  interacts  with  the  server  and  initiates  a  transfer 
from  the  user’s  account  to  an  offshore  institution.  When  the 
server  sends  a  notification  about  a  change  in  balance  in  the 
account,  the  incoming  data  (balance  amount)  is  manipulated 
to  reflect  a  different  number.  The  user  is  tricked  to  believe 
that  the  account  balance  is  intact.  A  bot  can  also  generate 
unauthorized  messages  on  behalf  of  the  server. 

3.3  Custom  Plugins 

Modern  botnets  implement  a  plug-in  framework  for  execut¬ 
ing  a  variety  of  attacks.  The  plug-in  framework  extends  the 
capability  of  botnets  by  allowing  the  cyber  criminals  to  write 
custom  code  that  can  be  easily  incorporated  into  running  bot¬ 
nets.  During  our  analysis  of  the  SpyEye  botnet  [1  5],  we  came 
across  interesting  plug-ins  that  are  used  for  data  exfiltration. 
These  are  as  follows: 

•  A  browser  certificate-grabber  plug-in  captures  informa¬ 
tion  about  various  certificates  that  are  present  in  the  browser 
storage  repository  and  are  used  to  verify  the  integrity  of  com¬ 
municating  parties. 

•  A  credit  card-grabber  plug-in  that  is  designed  specifical¬ 
ly  to  extract  credit  card  information  during  an  active  session 
with  a  bank’s  server. 

•  A  screenshot  stealer  and  video  grabber  plug-ins  that 
capture  screenshots  and  videos  of  the  browser  when  a  user 
performs  online  banking.  In  addition,  cyber  criminals  config¬ 
ure  plug-ins  in  such  a  manner  that  a  screenshot  is  captured 
based  on  the  movements  of  the  mouse  cursor. 

•  Cyber  criminals  can  also  design  plug-ins  specific  to  a 
bank’s  website.  For  example,  the  SpyEye  botnet  has  built-in 
information  stealing  plug-in  that  is  designed  specifically  for 
BofA. 

3.4  Mobile  Platforms:  SMS  and  HTTP  as  Data  Carriers 

Most  of  the  mobile  platforms  are  smart  phones  these  days 
that  provide  the  same  functionality  as  standard  computers,  so 
data  exfiltration  models  remains  the  same.  The  mobile  bots 
and  malicious  applications  can  perform  keylogging  and  moni¬ 
toring  of  data  that  is  transmitted  through  the  device.  Gener¬ 
ally,  mobile  bots  can  communicate  over  HTTP  and  control  the 
communication  flow.  The  primary  addition  in  the  data  exfiltra¬ 
tion  process  apart  from  standard  protocols  is  the  use  of  SMS 
as  a  carrier  for  transmitting  data.  It  means  the  mobile  bots 
can  steal  sensitive  information  and  use  the  SMS  capability 
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of  the  device  to  send  data  to  a  backend  domain  managed  by 
the  cyber  criminal.  Mobile  bots  can  perform  piggybacking  on 
legitimate  applications  and  steal  data  by  controlling  specific 
events  such  as  when  the  applications  send  data  to  a  banking 
server.  As  discussed  earlier,  mobile  bots  can  also  circumvent 
the  TFA  process  that  uses  SMS  (mobile)  as  a  second  chan¬ 
nel.  Zitmo  and  Spitmo  are  the  examples  of  mobile  malware 
that  support  this  fact. 

3.5  Phished  Web  Pages 

As  discussed  in  the  malware  design  section,  automated 
bots  are  used  for  sending  phishing  emails  with  luring  links. 
The  phishing  emails  are  constructed  in  a  sophisticated 
manner  that  it  becomes  easy  to  force  the  users  to  visit  the 
phished  website.  Once  the  user  clicks  the  embedded  link, 
the  browser  opens  the  phished  website,  which  contains  web 
forms  that  ask  specific  information  from  the  users.  Since  the 
web  pages  look  legitimate,  users  provide  sensitive  informa¬ 
tion  such  as  credentials,  credit  card  numbers,  etc.  This  is  an 
old-school  trick,  but  works  neatly  in  exfiltrating  data  from 
infected  end  user  machines. 

4.  Phase  4:  Underground  Business 

At  some  point,  stolen  data  must  be  converted  to  cash,  and 
for  that  we  turn  to  the  underground  economy.  In  the  under¬ 
ground  market,  there  are  three  basic  players:  sellers,  buyers 
and  money  mules.  Sellers  sell  the  data,  buyers  purchase  the 
data,  and  money  mules  convert  data  to  cash. 

4.1  Underground  Forums  and  IRC  Channels  as 
Business  Platforms 

Internet  Relay  Chat  (IRC)  [19]  channels  are  used  as  the 
primary  business  platform  in  the  underground  economy 
because  it  allows  cyber  criminals  to  remain  anonymous. 

Cyber  criminals  use  Virtual  Private  Network  (VPN)  to  initiate 
connections  to  IRC  servers  for  registering  communication 
channels.  With  the  existence  of  invisible  IRC,  the  communica¬ 
tion  channels  are  unreadable,  encrypted  and  untraceable. 

Once  data  is  successfully  stolen  from  infected  machines, 
cyber  criminals  need  to  sell  it.  During  our  study,  we  analyzed 
underground  forums  that  advertise  various  IRC  channels 
used  by  cyber  criminals  to  sell  sensitive  information.  Auto¬ 
mated  MIRC  scripts  regularly  advertise  updates  and  avail¬ 
ability  of  the  stolen  data.  Sellers  advertise  a  unique  ICQ  code 
with  an  IRC  channel  that  a  buyer  can  use  to  connect  directly 
so  the  buyer  is  unable  to  identify  the  seller. 

Data  is  sold  in  the  form  of  dumps  as  shown  in  Figure  1 
that  are  sent  to  the  buyer  once  the  seller  receives  payment. 

Sellers  require  money  in  the  form  of  Liberty-Reserve, 
Western  Union,  Money  Gram,  etc.,  which  are  e-currencies  that 
can  be  converted  into  Euros,  dollars  or  pounds.  E-currency 
involves  an  intermediate  third-party  who  does  not  reveal  the 
identity  of  the  buyer  or  the  seller  to  maintain  anonymity.  The 
underground  business  is  based  on  an  implicit  trust  between 
the  buyer  and  the  seller  that  the  seller  will  release  purchased 
data  upon  receiving  payment— there  is  no  third  party  to  turn 
to  for  resolving  disputes. 


Bank  login, Dumps, Fullz, Shopping, Bank  TRansfers, Online  transfer, Dumps  trackl&2,Etc 

Mailer, Rdp,Paypal,Cw, and  a  lot  more 

. . . -Contact - - 

ICQ  :  611785649 
YIM  :  lainhero 

MAIL  :  lainhero@yahoo.com 

- CW - 

1  US  (visa, master)  -  3  $ 

1  US  (Amex,dls)  =  4  $ 

1  UK  -  5  $ 

1  UK  (with  DOB  )  -  15  $ 

1  Ca  -  10  $ 

1  CA  (Amex,dis)  -  15  $ 

1  EU  -  15  $ 

1  EU  (Amex,dis)  -  17  $ 

1  US  (full  Info)  =  15  $ 

1  UK  (full  Info)  -  30$ 

Australia  (AU)  -  10  $ 

Switzerland  (VE)  -  15  $ 

France  (FR)  -  15  $ 

Germany  (GE)  -  15  $ 

Mexico  (MX)  -  12  $ 

New  Zealand  (NZ)  -  13  $ 

ITALY  -  15  $ 

Asian  cw(all  country)- 17$ 

And  many  country  orther... 

- MASTER  and  VISA  BIN - 

446278  -  446272  -  449352  -  449353  -  498824  -  415929  -  465902  -  492940 
492181  -  492182  -  492942  -  456735  -  454313  -  462785  -  453978 
518675  -  6759  -  5434  -  529930  -  552188  -  543429  -  5505 


Figure  1  -  Advertising  Dumps  of  the  Stolen  Bank  Data  ( Source :  Under¬ 
ground  Forum  <http://madtrade.org/>) 


HOME 


BUY  CARDS  BUY  ACCOUNTS  CART  MY  CARDS  MY  ACCOUNTS  MY  PROFILE  ADD  FUNDS  SUPPORT  $0.00  Q*jj 


Scare  h  Cards 


Total  Cards:  261S5 


Card  Number 

Last  Name 

Country 

State 

City 

SSN/DL 

ZIP 

DOB 

Price 

□ 

534356********** 

Smith 

US 

FL 

Orlando 

NO 

32801 

NO 

$2.00 

448595********** 

Sutter 

CA 

BC 

Cranbrook 

NO 

VIC  2R9 

NO 

S3.00 

m5~ 

491649********** 

Holloway 

GB 

NONE 

EAST 

BRADENHAM 

NO 

IP25  8ZE 

NO 

$4.00 

□ 

544008********** 

Preston 

GB 

NONE 

COLDBLOW 

NO 

DA5  4SZ 

NO 

$4.00 

□ 

471615********** 

Stevens 

GB 

NONE 

ALPHAMSTONE 

NO 

C08  5RF 

NO 

$4.00 

□ 

AQ7Q74**********  Mirhakln  PI  KIDNF  Warsaw*  NO  ND  U  fill 

FI  1 

Figure  2  -  Credit  Card  Shop  in  Action 

4.2  Credit  Card  (Plastique)  Shops 

Credit  card  shops  are  e-shops  that  exist  in  the  under¬ 
ground  market  to  sell  stolen  credit  card  information.  The 
credit  card  shops  are  similar  to  regular  e-commerce  websites. 
The  buyer  visits  various  underground  websites  to  find  infor¬ 
mation  about  the  credit  card  sellers,  and  obtain  the  address 
of  the  credit  card  shops  from  various  IRC  channels  and 
underground  forums.  The  buyer  then  has  to  register  with  the 
shop.  Once  the  registration  is  complete,  the  buyer  can  easily 
navigate  the  credit  card  shop  and  select  credit  cards  for  pur¬ 
chasing.  Currently,  the  stolen  credit  card  information  is  sold 
at  very  cheap  rates  ranging  from  $2  to  $20.  Figure  2  shows 
the  layout  of  one  current  credit  card  shop  we  found  during 
penetration  testing  of  domains  associated  with  malware. 
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- — ---Bank  Login - - Bank  Login  From  Usa  And  Eu  And  Uk  And  Asia  Is  AvaFabFe. 

AVAILABLE  BANK  LOGIN  : 

Scotia  On  Line 
Wachovia 

net  ba  nk.  com  m  ban  k  .com .  a  u 

Abbey 

HSBC 

Bremer  Online  Banking 

Flag  star  Bank 

KBC  Bank 

EnterCoinJ 

Postbank 

M&T 

Credit  Union 
WeMu 
Landmark 
Orchard 

American  Express 
Wells  Fargo 
ICICI  Bank 
Chase 

Pen  Air  Federal 
U.S.  Bank 
RBC 

First  Trust  Bank 
Banque  Nationals 
HDFC  Bank 

**You  can  contact  me  for  more  and  many  Bank  Logins  you  need* 

Transfers— - - - 

WU  Transfer  -  10%  upfront  of  whatever  amount  you  want  me  to  transfer  for  you 
eg:  If  you  want  $1000  you  will  have  to  pay  $200  upfront* 

I  make  Wire  transfer  and  cheque  transfer  to 

UK  and  US  banks  ..  HSBC  //  Nationwide  //Halifax  //Abbey  //  Capital  //  BOA  //  watchovia  // 

Barclays  //  FCU  /  Regions  /  Wells  //  etc,. 

Cost  is  10%  upfront  of  whatever  amount  you  want  me  to  transfer  for  you  (  will  accept  an  offer  depending  on  the  amount  to  be  transfered  ) 


Figure  3-  Service  Advertisements  for  Offshore  Money  Transfers 
( Source :  Underground  Forum  http://madtrade.org/) 


4.3  Money  Mules 

Money  mules  [18]  are  transfer  agents  hired  to  convert  data 
into  cash.  For  a  fee,  money  mules  use  credentials  (data)  to 
extract  money  from  a  bank  and  then  transfer  the  money  to 
offshore  accounts,  often  as  e-currency.  For  bank  transac¬ 
tions,  money  mules  must  usually  have  accounts  in  the  banks 
that  are  targeted  by  cyber  criminals  for  transferring  funds— a 
requirement  that  puts  mules  at  risk. 

Most  banks  have  strong  security  measures  for  transferring 
money  outside  a  bank,  but  little  security  for  transfers  within 
a  bank  so  it  is  common  to  transfer  within  a  bank.  We  assume 
that  credentials  have  been  collected  using  techniques  such 
as  form  grabbing  as  described  above. 

•  Sometimes  additional  information  is  needed  such  as  the 
user’s  account  including  registered  email  and  password.  It 
can  be  easily  collected  using  techniques  such  as  Form-grab¬ 
bing  or  Web  Injects  as  described  above.  If  the  bank  uses  TFA, 
the  associated  information  such  as  an  SMS  number  can  be 
gathered  in  the  same  way.  Hijacking  sessions  while  in  prog¬ 
ress  as  outlined  above  can  circumvent  one-time  passwords. 

•  With  that  information,  the  buyer  needs  to  enlist  a  mule 
so  the  buyer  needs  the  mule’s  name,  account  number,  and 
routing  number.  Given  restrictions  on  transfer  amounts,  mul¬ 
tiple  transactions  or  multiple  mules  may  be  needed. 

•  A  buyer  can  use  account  credentials  to  transfer  money 


to  a  mule  or  a  mule’s  credentials  can  be  provided  back  to 
the  seller  to  build  transactions  into  a  victim’s  live  session. 

The  seller  can  use  Wl  to  inject  the  mule’s  credentials  into 
web  pages  using  JavaScript.  The  script  causes  a  fraudulent 
transaction  during  a  user’s  session  to  transfer  money  directly 
to  the  mule’s  account. 

•  Once  money  has  been  transferred  to  a  mule’s  account, 
the  buyer  sends  a  confirmation  to  the  money  mule,  e.g.,  a 
screenshot.  Upon  receiving  the  confirmation,  the  money  mule 
moves  the  money  outside  the  bank.  The  transfer  may  be  to 
cash,  to  an  overseas  account,  to  merchandise,  or  to  e-curren¬ 
cy.  Upon  transferring  the  money,  the  mule  will  extract  a  fee 
for  their  services.  The  fee  can  vary  significantly  depending 
on  the  complexity  of  service  provided,  but  we  have  observed 
fees  ranging  from  2%  to  10%.  Figure  3  shows  an  advertise¬ 
ment  for  this  kind  of  service  in  the  underground  market. 
Money  mules  are  prevalent  in  regions  that  currently  lack 
strong  cyber  laws:  Eastern  Europe,  Russia,  Middle  East,  etc. 

•  An  optional  fourth  actor  may  be  present— a  bank  insider 
who  can  be  thought  of  as  a  type  of  money  mule.  A  bank 
employee  can  facilitate  overseas  transfers,  especially  large 
transfers.  An  overseas  transfer  needs  another  money  mule  at 
the  other  end  to  complete  the  transaction. 

Underground  markets  facilitate  the  buying  and  selling  of 
the  stolen  data  without  revealing  the  identity  of  the  players. 
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5.  Existing  Countermeasures  and  Defensive 
Mechanisms 

Banks  are  deploying  several  interesting  techniques  to  com¬ 
bat  online  fraud.  Several  of  them  are  discussed  as  follows: 

•  The  majority  of  banks  implement  SSL  that  protects  cus¬ 
tomers  from  network  layer  attacks  by  encrypting  the  channel 
between  end  points.  While  worthwhile,  this  practice  is  not 
suffice  to  combat  browser-based  data  exfiltration  attacks 
conducted  by  MitB  agents.  By  working  within  the  browser, 
the  attack  is  done  before  SSL  encrypts  the  data. 

•  Banks  also  deploy  multi-factor  authentication  systems 
using  multiple  channels  to  authenticate  clients.  A  popular 
one  is  TFA.  Display  tokens  such  as  RSA  Secure  ID,  Safenet’s 
e-token  and  Vasco  secure  tokens  use  either  time-based 

or  sequence-based  algorithms  to  generate  unique  tokens 
for  authentication  or  digital  transaction  signing.  The  user 
possesses  a  small  device  that  generates  tokens  at  regular 
intervals.  The  token  is  used  as  a  second  factor  in  authenti¬ 
cation.  For  example,  HSBC  bank  uses  RSA  Secure  ID,  and 
BofA  uses  Safe  Pass. 

•  In  a  variation  on  TFA,  some  banks  use  one-time  pass¬ 
words  [20]  for  authentication.  Banks  store  the  information 
about  users’  computers  including  IP  address,  browser,  geo 
IP  location,  etc.  If  the  bank’s  server  finds  that  the  information 
has  changed,  it  activates  the  OTP  scheme.  The  bank  will  have 
on  file  either  an  email  address  or  mobile  number  for  receiving 
the  OTP.  Using  this  second  channel,  the  OTP  is  sent  to  the 
user.  JP  Morgan  Chase  bank  is  an  example  of  a  bank  that 
implements  this  procedure. 

•  Banks  have  also  implemented  site-key  authentication  to 
thwart  phishing  attacks.  During  account  registration,  the  user 
selects  an  image  with  a  key  for  additional  verification.  The 
legitimate  account  login  page  includes  this  site  key  which 
assures  the  user  of  the  authenticity  of  the  website.  Typically, 
a  complete  site  key  consists  of  an  image,  selected  text  and 
challenge  questions.  Generally,  the  challenge  questions  are 
asked  when  the  connected  computer  is  not  recognized.  BofA 
and  HDFC  bank  are  examples  of  banks  that  incorporate  this 
functionality.  Note  that  this  technique  does  not  help  prevent 
MitB  attacks. 

•  Some  banks  recommend  third  party  monitoring  solutions 
such  as  Trusteer  Rapport  [1  7].  It  is  an  active  fraud  preven¬ 
tion  and  account  takeover  detection  solution,  and  users  are 
advised  to  install  it  before  using  banking  websites.  Compa¬ 
nies  like  Netqin  [28]  provide  mobile  anti-malware  solutions  to 
protect  the  integrity  of  mobile  devices. 

•  Banks  have  also  built  a  protection  against  keylogging 
attacks  in  the  form  of  virtual  keyboards  using  JavaScript.  This 
technique  prevents  keylogging  but  fails  to  protect  against 
form  grabbing.  A  few  banks  are  using  client-side  password 
encryption  to  defend  against  the  reuse  of  stolen  credentials. 
The  State  Bank  of  India  (SBI)  is  following  this  practice. 

•  Apart  from  technical  solutions,  banks  also  perform  foren¬ 
sic  investigative  analysis  of  money  fraud  problems  reported 
by  users.  This  includes  analyzing  the  anomalies  that  persist  in 
transactions.  The  anti-fraud  teams  collaborate  with  govern¬ 
ment  agencies  to  unmask  the  players  behind  these  frauds. 


Banks  are  taking  a  variety  of  steps  to  fight  against  a 
variety  of  cyber  crime,  but  none  prevent  current  MitB  at¬ 
tacks.  TFA  is  an  effective  defense  against  the  use  of  stolen 
credentials,  but  Wl  can  allow  criminals  to  collect  information 
on  the  second  channel.  TFA  raises  the  bar  and  Wl  provides  a 
work-around,  but  it  is  a  difficult  work-around. 

6.  State  of  Cyber  Laws 

Nations  with  advanced  economies  such  as  the  U.S.  or  the 
UK  have  begun  to  implement  cyber  laws.  The  biggest  prob¬ 
lem  in  eradicating  cyber  crime  globally  is  the  lack  of  central¬ 
ized  cyber  laws.  The  proposed  cyber  laws  are  country  specific 
and  cannot  be  enforced  across  borders  (except  to  a  limited 
extent  through  existing  treaties).  Quite  naturally,  countries 
are  most  concerned  with  cyber  crimes  that  impact  their  own 
institutions,  so  law  enforcement  agencies  are  more  interested 
in  investigating  or  prosecuting  cyber  criminals  that  exploit  the 
integrity  of  their  own  country’s  critical  infrastructure.  Con¬ 
tributing  to  the  problem  is  the  international  nature  of  cyber 
crime.  Cyberspace  has  no  borders  so  cyber  criminals  can 
work  anywhere.  Many  countries  have  still  not  implemented 
strong  cyber  laws  and  that  is  a  problem  for  managing  cyber 
crime  internationally.  The  laws  that  have  been  implemented 
vary  considerably— the  crimes  are  too  new  to  have  developed 
widespread  standards.  The  U.S.  is  one  of  the  leaders  in  mak¬ 
ing  and  implementing  cyber  laws  [16]  but  those  laws  cannot 
be  enforced  globally.  As  an  example,  U.S.  cyber  law  18  USC 
1030  deals  with  crimes  that  are  conducted  through  compro¬ 
mised  (unauthorized  access)  computers  and  further  using 
them  to  execute  identity  fraud  against  financial  institutions.  A 
convicted  person  can  get  five  to  10  years  in  prison.  Clearly, 
more  needs  to  be  done  and  countries  are  working  to  build 
a  robust  approach  against  cyber  crime.  The  efforts  must  be 
international,  if  we  are  to  build  a  secure  cyberspace. 

Conclusion 

In  this  paper,  we  presented  attack  methods  for  conduct¬ 
ing  online  bank  fraud.  To  carry  out  fraud,  cyber  criminals 
have  created  sophisticated  methods  of  malware  distribution, 
infection,  and  data  exfiltration.  One  important  trend  is  toward 
infecting  users’  systems  rather  than  attacking  banks’  servers. 
The  criminals  coerce  users  to  visit  malicious  domains  where 
drive-by  downloads  use  browser  vulnerabilities  to  download 
malware.  The  malware  hooks  browser  functions  to  allow 
form  data  (credentials)  to  be  grabbed  from  banking  sessions. 
On  mobile  devices,  malicious  applications  are  installed  that 
perform  piggybacking,  hijacking  communication  channels 
of  other  legitimate  applications  and  transmitting  data  using 
HTTP  or  SMS  to  remote  servers.  The  sensitive  information 
is  sent  to  cyber  criminals  who  convert  data  to  cash  using 
different  channels.  Some  banks  have  implemented  OTP  and 
TFA— and  these  authentication  systems  work  well  against 
some  attacks— but  they  fail  to  provide  adequate  protection 
against  MitB  and  MitMo  attacks.  As  a  result,  cyber  bank  fraud 
has  become  a  critical  problem  on  the  Internet.  To  secure 
online  banking,  multilayer  defenses  including  user  education 
are  needed.  ^ 
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DigitoL  Forensics 
in  the  Cloud 

Shams  Zawoad,  University  of  Alabama  at  Birmingham 
Ragib  Hasan,  University  of  Alabama  at  Birmingham 

Abstract.  Today’s  cloud  computing  architectures  often  lack  support  for  computer 
forensic  investigations.  Besides  this,  the  existing  digital  forensics  tools  cannot  cope 
with  the  dynamic  nature  of  the  cloud.  This  paper  explores  the  challenges  of  digital 
forensics  in  the  cloud,  possible  attacks  on  cloud-evidence,  and  mitigation  strategies 
against  those  challenges. 

Introduction 

Cloud  computing  offers  immense  opportunities  for  business 
and  IT  organizations  by  providing  highly  scalable  infrastructure 
resources,  pay-as-you-go  service,  and  low-cost  on-demand 
computing.  While  clouds  attract  diverse  organizations,  the 
security  and  trustworthiness  of  cloud  infrastructure  has  become 
a  rising  concern.  Clouds  can  be  a  target  of  attacks  or  can  be 
used  as  a  tool  to  launch  attacks.  Malicious  individuals  can  easily 
exploit  the  power  of  cloud  computing  and  can  perform  attacks 
from  machines  inside  the  cloud.  Many  of  these  attacks  are  novel 
and  unique  to  clouds. 

To  illustrate  the  use  of  clouds  for  malicious  purpose,  we  con¬ 
sider  the  following  hypothetical  scenario: 

Bob  is  a  successful  businessman  who  runs  a  shopping 
website  in  the  cloud.  The  site  serves  a  number  of  customers 
every  day  and  his  organization  generates  a  significant  amount 
of  profit  from  it.  Therefore,  if  the  site  is  down  even  for  a  few 
minutes,  it  will  seriously  hamper  not  only  their  profit  but  also  the 
goodwill.  Mallory,  a  malicious  attacker,  decided  to  attack  Bob’s 
shopping  website.  She  rented  some  machines  in  a  cloud  and 
launched  a  Distributed  Denial  of  Service  attack  to  the  shopping 
website  using  those  rented  machines.  As  a  result,  the  site  was 
down  for  an  hour,  which  had  quite  a  negative  impact  on  Bob’s 
business.  Consequently,  Bob  asked  a  forensic  investigator  to 
investigate  the  case.  The  investigator  found  that  Bob’s  website 
records  each  visiting  customer’s  IP  address.  Analyzing  the  visit¬ 
ing  customer  records,  the  investigator  found  that  Bob’s  website 
was  flooded  by  some  IP  addresses  which  are  owned  by  a  cloud 
service  provider.  Eventually,  the  investigator  issued  a  subpoena 
to  the  corresponding  cloud  provider  to  provide  him  the  network 
logs  for  those  particular  IP  addresses.  On  the  other  hand,  Mal¬ 
lory  managed  to  collude  with  the  cloud  provider  after  the  attack. 
Therefore,  while  providing  the  logs  to  the  investigator,  the  cloud 
provider  supplied  a  tampered  log  to  the  investigator,  who  had 
no  way  to  verify  the  correctness  of  the  logs.  Under  this  circum¬ 
stance,  Mallory  will  remain  undetected.  Even  if  the  cloud  pro¬ 
vider  was  honest,  Mallory  could  terminate  her  rented  machines 
and  leave  no  trace  of  the  attack.  Hence,  the  cloud  provider  could 
not  give  any  useful  logs  to  the  investigator. 
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Fig.  1 :  Process  Flow  of  Digital  Forensics 


To  identify  the  actual  attacker  in  the  above  attack  scenario,  we 
need  to  execute  digital  forensics  procedures  in  clouds.  Currently, 
extensive  research  is  going  on  to  protect  clouds  from  external 
or  internal  attackers.  However,  in  case  of  an  attack,  we  need 
to  investigate  the  incident.  Besides  protecting  the  cloud,  it  is 
important  to  focus  on  this  issue.  Unfortunately,  cloud  forensics  is 
not  yet  a  popular  research  topic  and  there  has  been  little  research 
on  adapting  digital  forensics  for  use  in  cloud  environments.  In 
this  paper,  we  address  the  problems  of  cloud  forensics  and  some 
mitigation  strategies,  which  have  significant  real-life  implications 
in  investigating  cloud-based  cyber-crime  and  terrorism. 

Understanding  Cloud  Forensics 

NIST  defines  digital  forensics  as  an  applied  science  for  “the 
identification,  collection,  examination,  and  analysis  of  data  while 
preserving  the  integrity  of  the  information  and  maintaining  a 
strict  chain  of  custody  for  the  data”  [1].  Figure  1  illustrates  the 
process  flow  of  digital  forensics.  Cloud  forensics  can  be  defined 
as  applying  all  the  processes  of  digital  forensics  in  the  cloud 
environment.  Ruan  et  al.  defined  cloud  forensics  as  a  subset 
of  network  forensics  [2],  because  cloud  computing  is  based 
on  extensive  network  access,  and  network  forensics  handles 
forensic  investigation  in  private  and  public  networks.  However, 
cloud  forensics  also  includes  investigating  file  systems,  process, 
cash,  and  registry  history.  Different  steps  of  digital  forensics 
shown  in  Figure  1  vary  according  to  the  service  and  deployment 
model  of  cloud  computing.  For  example,  the  evidence  collection 
procedure  of  Software-as-a- Service  (SaaS)  and  Infrastructure- 
as-a- Service  (laaS)  will  be  different.  For  SaaS,  we  solely  depend 
on  the  Cloud  Service  Provider  (CSP)  to  get  the  application  log. 

In  contrast,  in  laaS,  we  can  acquire  the  virtual  machine  image 
from  customers  and  can  initiate  the  examination  and  analysis 
phase.  In  the  public  deployment  model,  we  rarely  can  get  physi¬ 
cal  access  to  the  evidence,  but  this  is  guaranteed  in  the  private 
cloud  deployment  model. 


Network 


Servers 


OS 


Data 


1 


Application 

t _ 

f - 

Access  Control 

1 

Fig.  2:  Customers’ 
control  over  differ¬ 
ent  layers  in  differ¬ 
ent  service  model 


CrossTalk-September/October  2013  17 


SECURING  THE  CLOUD 


Why  Are  Clouds  Not  Forensics  Friendly? 

Several  characteristics  of  cloud  computing  complicate  the 
process  of  cloud  forensics.  As  the  storage  system  is  no  longer 
local,  law  enforcement  agents  cannot  confiscate  the  suspect’s 
computer  and  get  access  to  the  digital  evidence  even  with  a 
subpoena.  In  a  cloud,  each  server  contains  files  from  many 
users.  Hence,  it  is  not  feasible  to  seize  servers  from  a  data 
center  without  violating  the  privacy  of  many  other  benign  users. 
Moreover,  even  if  the  data  belonging  to  a  particular  suspect  is 
identified,  separating  it  from  other  users’  data  is  difficult.  The 
trustworthiness  of  the  evidence  is  also  questionable,  because 
other  than  the  cloud  provider’s  word,  there  is  no  usual  way  to 
link  a  given  evidence  to  a  particular  suspect.  The  following  is¬ 
sues  make  cloud  forensics  challenging. 

•  In  traditional  computer  forensics,  investigators  have  full 
control  over  the  evidence  (e.g.,  router  logs,  process  logs,  and 
hard  disks).  Unfortunately,  in  a  cloud,  the  control  over  data  varies 
in  different  service  models.  Figure  2  shows  the  control  of  cus¬ 
tomers  in  different  layers  for  the  three  different  service  models 
-  laaS,  PaaS,  and  SaaS.  Cloud  users  have  highest  control  in 
laaS  and  least  control  in  SaaS.  This  physical  inaccessibility  of 
the  evidence  and  lack  of  control  over  the  system  make  evidence 
acquisition  a  challenging  task  in  the  cloud.  For  example,  in  SaaS, 
customers  do  not  get  a  log  of  their  system,  unless  the  CSP  pro¬ 
vides  the  logs.  In  PaaS,  it  is  only  possible  to  get  the  application 
log  from  the  customers.  To  get  the  network  log,  database  log,  or 
operating  system  log  we  need  to  depend  on  the  CSP.  In  laaS, 
customers  can  only  get  the  operating  system  logs,  they  do  not 
have  access  to  network  or  process  logs.  For  example,  Amazon 
does  not  provide  load  balancer  logs  to  the  customers  [3],  and  it 
is  not  possible  to  get  MySql  log  data  from  Amazon’s  Relational 
Database  Service  [4]. 

•  Cloud  computing  is  a  multi-tenant  system,  while  traditional 
computing  is  a  single  owner  system.  To  give  an  analogy,  the 
cloud  can  be  compared  to  a  motel,  while  the  other  can  be  com¬ 
pared  to  a  personal  house.  In  a  cloud,  multiple  Virtual  Machines 
(VM)  can  share  the  same  physical  infrastructure,  i.e.,  data  for 
multiple  customers  can  be  co-located.  An  alleged  suspect  may 
claim  that  the  evidence  contains  information  of  other  users,  not 
her.  In  this  case,  the  investigator  needs  to  prove  to  the  court 
that  the  provided  evidence  actually  belongs  to  the  suspect. 
Conversely,  in  traditional  computing  systems,  a  suspect  is  solely 
responsible  for  all  the  digital  evidence  located  in  her  computing 
system.  Moreover,  in  the  cloud,  we  need  to  preserve  the  privacy 
of  other  tenants.  The  multi-tenancy  characteristic  also  brings 
novel  side-channel  attacks  [5]  that  are  difficult  to  investigate. 

•  Volatile  data  cannot  sustain  without  power.  Data  residing 
in  a  VM  are  volatile,  as  after  terminating  a  VM,  all  the  data  will 
be  lost.  In  order  to  provide  the  on  demand  computational  and 
storage  service,  CSPs  do  not  provide  persistent  storage  to  VM 
instances.  There  is,  though,  a  way  to  preserve  VM  data  by  stor¬ 
ing  an  image  of  the  VM  instance.  An  attacker  can  exploit  this 
vulnerability  in  the  following  way:  after  doing  some  malicious 
activity  (e.g.,  launch  DoS  attack,  send  spam  mail),  an  adversary 
can  terminate  her  VM  that  will  lead  to  a  complete  loss  of  the 
evidence  and  make  the  forensic  investigation  almost  impossible. 


A  malicious  user  can  also  fraudulently  claim  that  her  instance 
was  compromised  by  someone  else  who  had  launched  a  mali¬ 
cious  activity.  In  the  absence  of  any  evidence,  it  will  be  difficult 
to  prove  her  claim  as  false  via  a  forensic  investigation  [6]. 

•  Chain  of  custody  is  one  of  the  most  vital  issues  in  traditional 
digital  forensic  investigation.  Chain  of  custody  should  clearly 
depict  how  the  evidence  was  collected,  analyzed,  and  preserved 
in  order  to  be  presented  as  admissible  evidence  in  court  [7].  In 
traditional  forensic  procedure,  it  is  trivial  to  maintain  an  access 
history  of  time,  location,  and  person  to  access  the  computer, 
hard  disk,  etc.  of  a  suspect.  On  the  other  hand,  in  a  cloud,  we  do 
not  even  know  where  a  VM  is  physically  located.  Also,  investiga¬ 
tors  can  acquire  a  VM  image  from  any  workstation  connected 
with  the  internet.  The  Investigator’s  location  and  a  VM’s  physical 
location  can  be  in  different  time  zones.  Hence,  maintaining  a 
proper  chain  of  custody  is  challenging  in  clouds. 

•  Currently,  investigators  are  completely  dependent  on  CSPs 
for  acquiring  cloud  evidence.  However,  the  employee  of  a  cloud 
provider,  who  collects  data  on  behalf  of  investigators,  is  most 
likely  not  a  licensed  forensics  investigator  and  it  is  not  possible 
to  guarantee  his  integrity  in  a  court  of  law.  A  dishonest  employee 
of  a  CSP  can  collude  with  a  malicious  user  to  hide  important 
evidence  or  to  inject  invalid  evidence  to  prove  the  malicious  user 
is  innocent.  On  the  other  hand,  a  dishonest  investigator  can  also 
collude  with  an  attacker.  Even  if  CSPs  provide  valid  evidence  to 
investigators,  a  dishonest  investigator  can  remove  some  crucial 
evidence  before  presenting  it  to  the  court  or  can  provide  some 
fake  evidence  to  the  court  to  frame  an  honest  cloud  user.  In  tradi¬ 
tional  storage  systems,  only  the  suspect  and  the  investigator  can 
collude.  The  three-way  collusion  in  the  cloud  certainly  increases 
the  attack  surface  and  makes  cloud  forensics  more  challenging. 

Requirements  For  Forensics-Enabled  Cloud 

To  mitigate  the  challenges  that  we  discussed  above,  we 
identified  the  following  characteristics  that  a  forensics-enabled 
cloud  should  have: 

•  As  CSPs  do  not  provide  persistent  storage  to  VMs,  turning 
off  or  rebooting  a  VM  will  eventually  lose  all  the  data  residing 
in  that  VM.  Data  that  are  volatile  in  nature  must  be  stored  in 
persistent  databases  so  that  even  if  a  malicious  user  terminates 
her  virtual  machine,  we  can  still  gather  the  evidence.  One  possible 
solution  to  this  problem  is  that  CSPs  will  provide  a  continuous 
synchronization  API  to  customers.  Using  this  API,  customers 

can  preserve  the  synchronized  data  to  any  cloud  storage  e.g., 
Amazon  S3,  or  to  their  local  storage.  However,  if  the  adversary  is 
the  owner  of  a  VM,  this  mechanism  will  not  work.  Trivially,  she  will 
not  be  interested  in  synchronizing  her  malicious  VM.  To  overcome 
this  issue,  CSPs  by  themselves  can  integrate  the  synchronization 
mechanism  with  every  VM  and  preserve  the  data  within  their  in¬ 
frastructure.  CSPs  can  constantly  monitor  all  the  running  VMs  and 
store  the  volatile  data  in  a  persistent  storage.  The  volatile  data  can 
be  network  logs,  operating  system  logs,  and  registry  logs.  When  a 
VM  is  in  active  state,  CSPs  can  track  which  data  belongs  to  which 
VM.  Hence,  while  preserving  the  data,  CSPs  can  take  care  of 
segregating  the  data  according  to  VM  owner.  In  this  way,  multiple 
VM  owners’  data  will  not  be  co-mingled. 
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•  After  preserving  all  the  evidence,  CSPs  need  to  ensure  the 
integrity  of  the  evidence  in  order  to  prevent  collusion  between 
CSPs,  investigators,  and  cloud  users.  Without  integrity  preserva¬ 
tion,  the  validity  of  the  evidence  will  be  questionable  and  the 
defense  and  the  jury  can  object  about  it.  Generating  a  digital 
signature  on  the  collected  evidence  and  then  checking  the 
signature  later  is  one  way  to  validate  the  integrity.  Another  way 
is  preserving  the  proofs  of  past  data  possession  [8].  Preserv¬ 
ing  the  proofs  of  files  can  significantly  decrease  the  continuous 
synchronization  cost  and  at  the  same  time  ensure  the  integrity 
and  confidentiality  of  cloud  evidence.  Trusted  Platform  Module 
(TPM)  can  also  protect  the  integrity  of  cloud  evidence.  By  using 
a  TPM,  we  can  get  machine  authentication,  hardware  encryption, 
signing,  secure  key  storage,  and  attestation.  It  can  provide  the 
integrity  of  the  running  virtual  instance,  trusted  logs,  and  trusted 
deletion  of  data  to  customers. 

•  Besides  preserving  the  integrity  of  evidence,  CSPs  also 
need  to  provide  proper  chain  of  custody  information.  As  prov¬ 
enance  provides  the  history  of  an  object,  by  implementing  cloud 
provenance,  CSPs  can  provide  the  chronological  access  history 
of  evidence,  how  it  was  analyzed,  and  preserved,  which  can 
ensure  the  chain  of  custody  for  cloud  forensics.  However,  as 

all  the  evidence  and  the  access  histories  are  under  the  control 
of  CSPs,  they  can  always  tamper  with  the  provenance  record. 
Moreover,  from  the  provenance  data  in  the  cloud,  an  attacker 
can  learn  confidential  information  about  the  data  stored  in  the 
cloud.  To  protect  provenance  information  from  these  types  of 
attack,  we  need  a  secure  provenance  scheme  [9]. 


•  Considering  CSPs  are  preserving  all  the  evidence,  investiga¬ 
tors  will  be  still  dependent  on  CSPs  to  collect  evidence,  as  all  the 
cloud  evidence  resides  in  the  providers’  data  center.  CSPs  can 
play  a  vital  role  in  this  step  by  providing  a  web-based  manage¬ 
ment  console  or  providing  secure  API  to  law  enforcement  agen¬ 
cies.  Using  web  console  or  API,  customers  as  well  as  investiga¬ 
tors  can  collect  network,  process,  database  logs,  and  other  digital 
evidence  as  well  as  the  provenance  records  of  those  evidence. 

Moving  Towards  Regulatory  Compliant  Cloud 

As  cloud  computing  does  not  provide  the  facility  of  proper 
forensics  investigations,  it  cannot  be  used  to  store  healthcare, 
business,  or  national  security-related  data,  which  require  audit 
and  regulatory  compliance.  Auditability  is  a  vital  issue  to  make 
the  cloud  compliant  with  the  regulatory  acts,  e.g.,  The  Sarbanes 
Oxley  (SOX)  Act  [1 0]  or  The  Health  Insurance  Portability  and 
Accountability  Act  (HIPAA)  [11].  According  to  SOX,  financial 
information  must  reside  in  auditable  storage  that  the  CSPs  can¬ 
not  provide  currently.  Business  organizations  cannot  move  their 
financial  information  to  a  cloud,  as  it  does  not  comply  with  the 
SOX  act.  As  cloud  infrastructures  do  not  comply  with  HIPAA’s 
forensic  investigation  requirement,  hospitals  also  cannot  move 
their  patients’  confidential  medical  records  to  cloud  storage.  A 
forensics-enabled  cloud  architecture  that  satisfies  all  the  re¬ 
quirements  stated  in  the  previous  section  will  definitely  increase 
the  auditability  of  a  cloud  environment.  By  deploying  such  an 
architecture,  we  will  be  able  to  store  and  provide  the  types  of 
evidence  from  which  we  can  get  all  the  activities  of  cloud  users. 
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Business  and  healthcare  organizations  are  the  two  most  data  con¬ 
suming  sectors.  Hence,  cloud  computing  cannot  reach  its  goal  without 
including  these  two  sectors.  These  sectors  are  spending  extensively  to 
make  their  own  regulatory-compliant  infrastructure.  A  regulatory-compliant 
cloud  can  save  this  huge  investment.  We  need  to  solve  the  audit  compli¬ 
ance  issue  to  bring  more  customers  into  the  cloud  world.  Implementing 
an  architecture  that  allows  cloud  forensics  investigations  will  make  clouds 
more  compliant  with  such  regulations,  leading  to  widespread  adoption  of 
clouds  by  major  businesses  and  healthcare  organizations. 

Conclusion 

In  this  paper,  we  discussed  the  technical  challenges  of  executing 
digital  forensic  investigations  in  a  cloud  environment  and  presented  the 
requirements  to  make  clouds  forensics -friendly.  Collecting  trustworthy 
evidence  from  a  cloud  is  challenging  as  we  have  very  little  control  over 
clouds  compared  to  traditional  computing  systems.  For  now,  investigators 
need  to  depend  on  the  CSP  to  collect  evidence  from  a  cloud.  To  make 
the  situation  even  worse,  there  is  no  way  to  verify  whether  the  CSP  is 
providing  correct  evidence  to  the  investigators,  or  the  investigators  are 
presenting  valid  evidence  to  the  court.  Thus,  we  need  to  build  a  trust 
model  to  preserve  the  trustworthiness  of  evidence.  For  forensics  data 
acquisition,  CSPs  can  shift  their  responsibility  by  providing  a  robust  API 
or  management  console  to  acquire  evidence.  However,  the  CSPs  need  to 
come  forward  to  resolve  most  of  these  issues.  Creating  a  secure  model 
for  cloud  forensics  is  very  important  as  it  will  lead  to  more  trustworthy 
clouds,  allowing  their  adoption  in  sensitive  application  domains  such  as 
defense,  business,  and  healthcare. 
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AbstractJdentity  management  (IdM)  is  the  complex  and  constantly  evolving 
practice  of  identifying  individuals  and  controlling  their  access  to  a  network  and  con¬ 
nected  resources.  IdM  research  focuses  primarily  on  making  systems  secure  while 
the  quality  of  the  user  experience  is  largely  ignored.  This  article  explores  reasons 
why  creating  a  user-centric  IdM  paradigm  has  become  necessary,  discusses  exist¬ 
ing  efforts  to  make  IdM  more  user  centric,  and  presents  one  possible  implementa¬ 
tion  of  user-centric  IdM  that,  in  theory,  could  leverage  mobile  devices. 

Introduction 

Computer  users  are  becoming  increasingly  aware  of  the 
dangers  engendered  by  the  Internet.  Breaches  of  personal 
privacy  and  identity  theft  have  created  an  overwhelming  need 
for  security.  To  address  these  challenges,  researchers  are  en¬ 
gaged  in  the  growing  field  of  identity  management  (IdM),  which 
involves  strategies  for  identifying  individuals  in  a  network  and 
controlling  their  access  to  its  resources.  To  date,  IdM  research 
has  largely  focused  on  system  security  while  often  ignoring  the 
quality  of  the  user  experience.  As  a  result,  IdM  practices  have 
made  systems  more  secure  but  harder  to  use. 

There  is  growing  recognition  of  a  need  to  address  the  imbal¬ 
ance  between  security  and  usability.  For  example,  in  April  201 1 
the  White  House  gave  NIST  a  mandate  to  partner  with  the  pri¬ 
vate  sector  to  make  online  transactions  both  easier  and  safer  by 
establishing  the  Identity  Ecosystem  [1].  Collaborators  envision 
this  ecosystem  as  a  user-centric  environment  that  will  support 
identity  authentication  in  ways  that  are  convenient  for  users.  The 
goal  is  to  provide  developers  with  mechanisms  to  build  systems 
that  are  both  secure  and  user  friendly.  This  article  contributes  to 
this  effort  by  exploring  what  a  user-centric  IdM  paradigm  might 
look  like,  how  it  could  be  implemented,  and  the  implications  of 
that  implementation. 

IdM  research  provides  significant  value  to  the  U.S.  DoD. 
Establishing  a  viable  identity  ecosystem  will  encourage  the 
commercial  and  industrial  sectors  to  invest  in  improved  identity 
management  and  security  mechanisms.  The  DoD  could  then 
adopt  these  tools,  techniques,  and  processes  to  improve  the 
security  of  DoD  identities  and  systems. 

The  Present  State  of  IdM 

One  symptom  of  the  heightened  need  for  security  is  the 
growing  number  of  passwords  that  users  must  keep  track  of.  A 
few  years  ago,  most  users  had  only  a  handful  of  passwords  to 
remember;  a  naive  user  might  have  kept  the  same  password  for 
all  systems.  Today,  casual  computer  users  need  a  dozen  pass¬ 
words,  and  sophisticated  users  need  several  dozen.  Some  users 
might  need  to  manage  over  100  passwords  [2]. 


However,  computer  users  have  bigger  worries.  Password  theft 
plays  a  less  significant  role  in  identity  theft  than  phishing  and 
keylogging  [3],  and  viruses,  worms,  malware,  and  other  malicious 
software  continue  to  increase  [4].  Aspiring  thieves  who  do  not 
have  the  technical  skills  to  perform  attacks  themselves  can  buy 
malware  that  others  have  created  [4,  5].  And  the  Stuxnet  worm 
has  shown  that  cyber-attacks  can  be  powerful  enough  to  be 
used  as  weapons  of  international  espionage  or  even  war  [6,  7]. 
Despite  lack  of  expertise  in  security  and  IdM,  users  are  often  the 
first  (and  sometimes  the  only)  line  of  defense  against  ever  more 
dangerous  forms  of  attack,  such  as: 

•  Wifi  hacking  [8,  9] 

•  Compromised  personal  devices  and  infrastructure 
systems  [10, 11] 

•  Social  engineering  [2,  3, 12] 

•  Cookie  sniffing  [1 3, 1 4] 

•  Timing  attacks  [1 5] 

•  Man-in-the-middle  (M ITM)  attacks  [1 6, 1 7] 

•  Insecure  websites  [2] 

•  Broken  encryption  attributed  to  GPU  (graphics 
processing  unit)  [1 8]  and  quantum  computing  attacks  [1 9] 

Most  users  find  these  problems  too  complex  to  manage 
[17].  As  a  result,  many  ignore  security  advice  or  engage  in  poor 
practices  such  as  using  simplistic  passwords  or  writing  pass¬ 
words  on  pieces  of  paper  near  their  computers  [20,  21  ].  While 
the  security  community  belittles  users  for  these  approaches 
[14],  some  security  experts  state  that  this  behavior  is  not  only 
predictable  but  also  rational,  given  the  overwhelming  amount  of 
security  advice  that  users  receive  [3,  10,  22,  23]. 

Clearly,  average  users  lack  the  knowledge  and  skills  needed 
to  manage  their  own  security.  To  resolve  this  dilemma,  a  radical 
shift  must  take  place  in  IdM  research.  New  directions  in  IdM 
research  must  meet  the  challenge  for  improved  security  by  ad¬ 
dressing  a  growing  number  of  threats  while  reducing  security 
demands  on  the  user.  The  user-centric  IdM  model  proposed  in 
this  article  provides  a  potential  solution. 

Changing  the  Game  with  User  Centricity 

Because  many  users  lack  sufficient  knowledge  to  manage 
their  own  online  identity,  any  viable  IdM  strategy  has  three  goals: 

1.  Improved  Threat  Resilience:  Increase  the  capability 
of  users  to  resist  threats. 

2.  Improved  Credential  Management:  Improve  the  capabil 
ity  of  users  to  manage  an  arbitrary  number  of  credentials. 

3.  Reduced  User  Load:  Decrease  the  knowledge  and  effort 
required  of  users  to  resist  threats. 

Unfortunately,  these  goals  tend  to  be  contradictory.  The  typi¬ 
cal  approach  to  improving  the  security  of  a  system  addresses 
threats  individually,  which  tends  to  increase  system  complex¬ 
ity  and  restrictions  on  user  access  and  require  more  skills  and 
knowledge  of  the  user  to  ensure  safe  behaviors.  Moreover,  each 
system  addresses  problems  in  different  ways,  which  leads  to 
unique  IdM  requirements  for  each  system  with  which  a  user 
interacts.  Thus,  the  goal  of  increasing  threat  resilience  overrides 
the  user-based  goals  of  improving  credential  management  and 
reducing  user  load. 
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As  a  result,  users  cope  with  increased  complexity  by  relying 
on  bad  security  practices  [24],  such  as  reusing  passwords  [25, 
26],  practicing  bad  password  construction  [25,  27,  28],  and  ne¬ 
glecting  basic  mobile  device  security  practices  such  as  setting 
an  access  PIN  [29]. 

Contradictions  among  IdM  goals  can  potentially  be  resolved 
through  a  user-centric  IdM  paradigm.  Because  there  is  no 
universal  definition  of  what  user-centric  IdM  entails,  here  is  a 
simple  definition: 

A  user-centric  IdM  system  places  the  user  priorities  of  improved 
credential  management  and  reduced  user  load  at  the  same  impor¬ 
tance  as  the  system  owner  priority  of  improved  threat  resilience. 

This  means  that  improvements  to  threat  resilience  must  not 
increase  user  requirements  or  degrade  credential  management 
capabilities.  The  IdM  field  will  need  novel  and  technologically 
advanced  solutions  to  eliminate  threats  without  making  users’ 
lives  harder.  For  example,  eliminating  passwords  and  replacing 
them  with  rolling  PINs  combined  with  multifactor  or  multichan¬ 
nel  authentication  reduces  both  demands  on  the  user  and 
threats  such  as  brute-force  attacks,  replay  attacks,  and  MITM 
attacks.  These  methods  would  prevent  many  poor  user  practices 
because  complex  passwords  would  no  longer  be  required  for 
using  networked  services.  Therefore,  user-centric  IdM  para¬ 
digms  with  advanced  security  mechanisms  could  result  in  more 
secure  systems  that  are  also  easier  to  use. 

Despite  the  perceived  advantages  of  a  user-centric  approach, 
for  many  reasons  user-centric  IdM  systems  have  not  become 
ubiquitous.  The  rest  of  this  article  examines  some  of  these  is¬ 
sues  and  identifies  existing  and  potential  solutions. 

The  User-Centric  IdM  Paradigm 

To  theorize  about  the  user-centric  IdM  system  of  the  future,  it 
is  important  to  examine  existing  work.  This  section  also  presents 
a  vision  of  a  user-centric  IdM  system  and  discusses  the  associ¬ 
ated  risks,  benefits,  shortcomings,  and  opportunities. 

History 

Many  groups  have  tried  to  improve  IdM  in  a  way  that  embraces 
usability  as  a  key  driver  along  with  security.  Two  of  the  most 
prominent  developments  are  the  Web  single  sign-on  (SSO)  solu¬ 
tions  of  OpenID  and  Microsoft  InfoCard  [24],  which  have  provided 
an  initial  model  for  how  a  single  login  for  all  Internet  services 
might  work.  The  Kantara  Initiative  [30]  and  the  Burton  Group  [31] 
have  explored  a  wide  range  of  technology  and  policy  solutions. 
Similarly,  identity  experts  such  as  Dick  Hardt  have  contributed 
to  the  concept  of  “Identity  2.0”  [32].  This  set  of  principles  and 
practices  demonstrates  how  a  next-generation  IdM  system  could 
work  and  provides  the  foundation  for  many  qualities  of  the  pro¬ 
posed  user-centric  IdM  system.  Finally,  developers  of  password 
management  mechanisms  such  as  Mozilla  BrowserlD  [33]  and 
manager  programs  such  as  Billeo  have  begun  to  instantiate  basic 
implementations  of  user  centralization  [2,  24,  34].  Unfortunately, 
none  of  the  commercial  approaches  have  been  widely  adopted. 
The  DoD  Common  Access  Card  (CAC)  program  represents  the 
only  wide-scale  single-identity  solution  that  can  be  considered 
successful.  However,  like  most  DoD  programs,  the  tailoring  to  the 
military  domain  limits  the  applicability  to  more  general  domains. 


The  Vision:  Building  on  Existing  Models 

There  are  several  reasons  why  existing  user-centric  IdM 
efforts  have  failed  to  reach  critical  mass.  However,  the  causes 
for  failure  are  not  intrinsic  to  the  user-centric  IdM  paradigm  and 
could  be  addressed  in  a  way  that  creates  a  viable  model  for  IdM 
while  retaining  the  essential  characteristics  of  user  centricity. 
Therefore,  the  proposed  vision  of  IdM’s  future  builds  on  several 
fundamental  characteristics  of  existing  web-SSO  systems  and 
the  Identity  2.0  paradigm.  These  characteristics  include: 

•  Centralization  of  all  identity  decisions  to  a  single 
point  or  portal 

•  Ubiquity  across  all  network-enabled  services 

•  Elimination  of  multiple  credentials 

These  characteristics  are  necessary  but  not  sufficient  to  meet 
the  user  IdM  goals.  Four  additional  characteristics  are  necessary  for 
a  refined  vision  of  IdM: 

•  Elimination  of  passwords  as  the  primary  credential 

•  Use  of  advanced  security  mechanisms  such  as  digital 
certificates,  rolling  PINs,  and  multifactor  and 
multichannel  authorization 

•  Leverage  of  mobile  devices  for  centralization 

•  Security  managed  by  qualified  security  professionals, 
rather  than  by  users 

Implementing  a  user-centric  IdM  system  with  these  character¬ 
istics  would  increase  both  security  and  ease  of  use.  First,  threat 
resilience  would  improve  through  migration  to  non-password- 
based  mechanisms  and  offloading  of  security  maintenance  to 
qualified  professionals.  Second,  credential  management  would 
improve  through  the  removal  of  passwords  and  the  simplification 
to  a  single  credential.  Finally,  user  load  would  be  reduced  due  to 
password  elimination,  single-credential  centralization  of  access, 
and  offloading  the  need  for  deep  technical  knowledge  to  trained 
security  professionals. 

While  this  vision  would  effectively  meet  both  the  user  and 
the  system  goals  of  IdM,  it  must  also  address  several  additional 
issues  for  the  proposed  model  to  be  viable. 

Issue  1:  Centralization 

There  is  no  question  that  centralization  is  a  key  risk  to  accept¬ 
ing  and  implementing  the  vision  of  user-centric  IdM.  Central¬ 
izing  all  identity  decisions  creates  a  single  point  of  failure  for 
accessing  services,  a  single  point  of  access  for  malicious  users 
to  steal  credentials  [35,  36],  and  a  single  point  of  vulnerability  to 
innocent  mistakes  (e.g.,  misplacing  a  keychain)  [29]. 

However,  the  benefits  may  now  outweigh  the  risks.  As 
previously  discussed,  the  reality  is  that  users  are  not  qualified 
to  handle  their  own  security  [3,  29].  Centralization  makes  it 
possible  for  users  to  leverage  trained  security  professionals  to 
keep  their  identity  secure  across  all  of  the  network  services  they 
use.  This  is  the  only  proven  way  to  manage  the  complex  threat 
environment  that  now  exists  [34,  37].  By  centralizing  all  identity 
decisions  to  a  single  point  controlled  by  a  single  organization,  a 
user’s  entire  identity  landscape  can  be  protected  in  a  consistent 
and  comprehensive  way.  Centralization  can  also  simplify  the 
problem  of  credential  management  and  help  reduce  security 
risks  induced  by  poor  user  practices.  It  can  also  streamline 
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To  drive  sufficient  demand,  the  proposed  vision  must  meet  user  IdM  goals  with  a  high  degree 
of  success.  However,  providing  a  system  that  is  sufficiently  attractive  to  users  to  drive  a 
critical  mass  of  demand  does  not  result  in  an  economically  viable  organization.  Infrastructure 
costs  and  salaries  of  the  security  professionals  would  be  significant  burdens  to  support. 


recovery  from  compromise  because  the  individual  user  maps 
to  a  single  identity  location  that  can  be  aggressively  monitored, 
leading  to  improvements  in  compromise  detection  and  notifica¬ 
tion.  Centralization  also  reduces  user  load  significantly. 

The  risks  associated  with  the  highly  distributed  IdM  solu¬ 
tions  of  today  that  place  so  much  responsibility  on  users  have 
reached  a  tipping  point.  Without  centralization,  users  must 
manage  their  own  credentials.  And  as  the  number  of  credentials 
managed  by  the  average  user  continues  to  increase,  users  will 
begin  to  look  at  the  burden  of  credential  management  as  a  limit¬ 
ing  factor  to  the  services  that  they  are  willing  to  use. 

Issue  2:  Proper  Security  Mechanisms  to  Protect 
the  Identity  Store 

The  complexity  of  securing  a  centralized  access  point  for 
identity  is  considerable,  but  the  security  community  generally 
agrees  that  password  schemes  do  not  provide  a  sufficient  level 
of  security  and  must  be  phased  out  [3,  1 2,  22,  25,  38-41  ]. 
Existing  mechanisms  that  can  replace  password  schemes  or 
augment  non-password  schemes  include: 

•  Certificates,  such  as  those  used  for  wireless  access 
by  the  DoD  CAC  [42]; 

•  Rolling  PIN  numbers,  such  as  those  used  by  RSA 
SecurlD  devices  [43]; 

•  Two-factor  authentication  [1 3, 44,  45]; 

•  Automatic  update  devices  [34]; 

•  Modern  encryption  technologies  [35]; 

•  Disposable  accounts  and  similar  privacy  approaches 
[2,10, 46];  and 

•  Privacy-enhancing  software  [47-49] 

However,  given  the  scope  of  the  proposed  vision  and  the 
complex  mosaic  of  security  technologies,  these  mechanisms  are 
not  sufficient  to  guarantee  secure  centralization.  The  greatest 
threat  to  any  centralized  identity  store  is  that  many  systems 
used  by  many  users  could  be  compromised  by  a  single  failure. 
Therefore,  security  of  the  centralized  data  store  will  likely  require 
the  development  of  additional  security  mechanisms. 

Issue  3:  Organizational  Viability 

The  proposed  vision  focuses  on  the  idea  of  having  central  points 
of  access  for  all  user  identity  decisions.  Combined  with  the  idea 
that  trained  security  professionals  manage  the  security  of  this  point 
or  portal,  it  is  clear  that  the  vision  requires  creating  one  or  more 
organizations  that  manage  access  for  users  to  the  network  services 
they  use.  An  obvious  question  involves  how  this  differs  from  the 
web-SSO  solutions  discussed  above,  such  as  Open  ID  or  InfoCard. 
The  answer  is  that  the  proposed  vision  has  the  potential  of  wide¬ 
spread  adoption,  unlike  existing  web-SSO  solutions.  To  understand 
why,  it  is  necessary  to  examine  the  reasons  that  systems  such  as 
Open  ID  have  not  attained  widespread  adoption. 


As  the  DoD  CAC  has  demonstrated,  strong  incentives  are 
required  to  enforce  cross-organizational  use  of  a  single  identity. 
For  the  CAC,  the  DoD  mandate  provided  these  incentives.  In  the 
commercial  world,  the  only  incentive  with  sufficient  strength  to 
make  organizations  work  together  is  financial.  Because  web- 
SSO  approaches  such  as  OpenID  and  InfoCard  are  noncom¬ 
mercial,  there  is  little  to  no  incentive  for  service  providers  to 
integrate  themselves  into  the  existing  web-SSO  systems  [50]. 

In  fact,  the  only  incentives  for  using  the  available  web-SSO 
solutions  are  managerial  in  nature  (a  reduction  in  overhead  of  user 
management),  but  there  are  also  strong  disincentives  for  using 
these  services.  For  example,  with  existing  SSO  solutions,  service 
providers  assume  all  of  the  liability  for  compromise  even  though 
they  do  not  control  login  data;  they  lose  access  to  user  data,  which 
has  proven  valuable  for  advertising  purposes;  and  they  must  rely 
on  external  services  over  which  they  have  no  control.  Therefore,  it 
has  been  exceedingly  difficult  to  establish  business  agreements 
between  service  providers  and  web-SSO  providers  because  the 
incentives  to  do  so  are  overwhelmingly  negative  [24,  31  ]. 

This  means  that  to  meet  the  goal  of  ubiquity  across  all 
networked  services,  the  proposed  vision  of  a  user-centric  IdM 
system  would  have  to  be  implemented  by  a  company  that  could 
establish  strong  incentives  for  integrating  with  their  system.  The 
only  incentive  proven  to  be  sufficient  to  drive  service  providers 
to  integrate  with  an  external  provider  to  manage  identity  is  user 
demand  [24].  So  to  drive  sufficient  demand,  the  proposed  vision 
must  meet  user  IdM  goals  with  a  high  degree  of  success.  How¬ 
ever,  providing  a  system  that  is  sufficiently  attractive  to  users  to 
drive  a  critical  mass  of  demand  does  not  result  in  an  economi¬ 
cally  viable  organization.  Infrastructure  costs  and  salaries  of  the 
security  professionals  would  be  significant  burdens  to  support. 

Implementing  User-Centric  IdM 

In  this  proposed  vision  of  IdM’s  future,  an  organization, 
nominally  called  a  personal  identity  provider  (PldP),  could  deliver 
services  in  a  way  that  is  consistent  with  the  proposed  user¬ 
centric  model.  The  responsibilities  of  such  a  company  would 
be  to  provide  users  with  personalized  control  of  their  identity 
landscape,  mediate  access  between  the  user  and  any  service 
that  the  user  wishes  to  access,  ensure  that  the  user’s  identity  is 
secure,  and  prepare  for  and  respond  to  compromise. 

Delivering  Identity  Services 

To  deliver  services  in  a  way  that  satisfies  the  user’s  needs,  the 
PldP  company  of  the  future  would  have  to  meet  several  require¬ 
ments.  First,  it  would  be  staffed  by  security  professionals  qualified 
to  manage  the  persistent  threats  to  users  and  to  internal  systems. 
Second,  the  company  would  have  close  agreements  with  the 
majority  of  service  providers,  as  well  as  competing  PldP  compa¬ 
nies,  to  ensure  that  the  connections  are  reliable  and  secure.  Third, 
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the  company  would  have  customer  service  and  legal  support  that 
are  sufficient  to  handle  inevitable  compromises.  If  the  company 
met  these  requirements,  it  would  provide  secure  identity  services, 
offer  access  to  a  wide  range  of  services,  and  accept  the  burden 
of  responsibility  for  securing  user  data  and  privacy. 

Using  Mobile  Devices 

As  many  daily  tasks  become  folded  into  the  capabilities  of 
modern  smartphones— such  as  calendar  management,  email, 
and  financial  transactions— the  lives  of  technology-enabled 
users  are  increasingly  centered  on  their  mobile  devices.  In  this 
proposed  vision  of  IdM’s  future,  a  smartphone  or  similar  mobile 
device  could  host  an  application  that  would  allow  users  to  see, 
manage,  and  understand  their  personal  identity  landscapes. 

Such  an  application  would  offer  a  centralized,  simplified  IdM 
experience  for  users. 

The  mobile  device  also  provides  the  necessary  hardware 
platform  to  support  improved  security  technologies,  such  as 
two-factor  authentication,  single-use  passwords,  and  disposable 
accounts.  While  efforts  to  bring  these  technologies  to  mobile  de¬ 
vices  are  not  yet  mature,  prototypes  are  likely  to  be  fielded  within 
the  next  few  years,  especially  considering  the  extensive  efforts 
that  the  DoD  has  made  to  leverage  smartphones  for  common  use 
[42,  51-55]  and  even  for  processing  classified  data  [56].  Work 
on  the  mobile  CAC  reader,  in  particular,  demonstrates  that  a  se¬ 
cure,  non-password-based  credential  can  reside  either  on  or  near 
a  smartphone  and  provide  user-centric  authentication  [42]. 

While  such  devices  are  not  yet  pervasive,  the  incredible  growth 
of  cell  phones  [57]  bolsters  the  argument  that  generalized  mobile 
device  use  is  inevitable  in  the  near  future.  It  is  therefore  not 
unrealistic  to  expect  that  in  the  future  an  average  user  will  have 
access  to  a  mobile  device  that  supports  the  proposed  system. 

Creating  a  Viable  Economic  Model 

Presenting  a  viable  business  case  for  the  type  of  organiza¬ 
tion  proposed  is  beyond  the  scope  of  this  paper.  However,  it  is 
possible  to  speculate  about  how  such  an  organization  might 
operate.  One  way  to  think  about  the  PldP  model  is  as  a  type  of 
insurance  company.  Just  as  an  insurance  company  does,  the 
PldP  organization  would  accept  the  risk  of  compromise  for  its 
customers,  provide  a  centralized  service,  guarantee  it  to  be  safe 
as  long  as  it  is  used  correctly,  proactively  manage  security  as 
new  threats  emerge,  and  receive  a  periodic  fee  for  doing  so. 

To  have  sufficient  control  over  user  identity  to  make  such  an 
arrangement  possible,  the  PldP  would  implement  the  infrastruc¬ 
ture  that  provides  users  with  the  centralized  point  of  access. 

This  would  involve  technology  infrastructure  for  managing 
identities,  interfaces  (web  and/or  mobile),  and  agreements  with 
service  providers.  The  necessary  capabilities  and  policies  would 
likely  emerge  as  user-centric  PldP  services  evolve. 

This  simplified,  personalized,  unified  IdM  experience— built  on 
the  necessary  infrastructure  and  offered  by  a  trusted  company 
that  is  willing  to  take  financial  and  legal  responsibility  for  secu¬ 
rity  compromise— would  attract  sufficient  customers  to  create 
a  viable  business  model.  Just  as  people  are  willing  to  purchase 
health  insurance  because  they  cannot  foresee  and  control 


health  events,  it  is  possible  that  a  large  number  of  users  would 
pay  to  resist  unforeseen  online  events  and  possible  negative 
consequences  to  their  privacy,  credit,  and  finances.  Many  people 
are  already  paying  for  services  that  provide  offline  identity  pro¬ 
tection,  such  as  LifeLock  [58]. 

In  addition  to  the  standard  insurance  company  approach  of  a 
monthly  fee,  other  strategies  could  encourage  adoption  of  the 
service  until  it  becomes  ubiquitous.  One  alternative  is  to  allow 
users  to  explicitly  sell  personal  information  to  the  PldP  com¬ 
pany-based  on  their  login  activity— in  exchange  for  free  service. 
Given  the  profit  potential  of  tracking  online  activity  for  advertis¬ 
ing  purposes  [59],  this  option  could  ensure  business  viability.  If 
the  PldP  is  explicit  about  the  tradeoff  of  free  service  for  less 
privacy,  the  privacy  concerns  that  users  typically  raise  when  ser¬ 
vice  providers  track  their  activity  are  unlikely  to  be  a  problem.  As 
demonstrated  by  the  lukewarm  reception  to  Google  Buzz  [60] 
versus  the  much  warmer  response  to  Google+  [61],  users  are 
far  more  willing  to  share  and  expose  personal  data  when  they 
feel  that  they  control  the  sharing. 

Summary 

Current  IdM  systems  are  unsustainable.  People  have  dozens  of 
accounts,  each  accessible  through  unique  passwords  of  ever- 
increasing  complexity,  while  security  threats  come  from  every  di¬ 
rection.  It  is  time  to  change  the  game.  The  emergence  of  personal 
IdM  companies  that  adopt  user-centric  identity  management 
models  in  an  age  of  ubiquitous,  generalized  mobile  devices  could 
set  the  stage  for  such  a  revolution.  The  computer  security  industry 
should  take  this  bold  step  forward  and  embrace  a  new  paradigm 
of  identity  management.  There  is  no  question  that  changing  the 
game  will  be  difficult;  however,  there  is  also  no  question  that  the 
game  we  are  currently  playing  has  already  been  lost. 
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Abstract.  In  a  Service-Oriented  Architecture  (SOA)  system,  services  contain 
operations  with  openly  defined  input  and  output  parameters.  While  satisfying  func¬ 
tional  requirements,  a  service  also  exposes  its  attack  surface  via  published  opera¬ 
tions,  open  protocols,  and  accessible  data  as  an  adverse  side  effect,  which  makes 
it  susceptible  to  exploitation  by  malicious  actors.  With  this  context,  it  is  a  challenge 
to  build  an  SOA  environment  such  that  it  is  resilient  in  the  face  of  hostile  attacks. 

In  this  paper,  we  propose  an  approach  to  design  services  such  that  their  attack- 
ability  can  be  controlled  and  intrusion  tolerance  guaranteed  despite  the  exposed 
attack  surface.  Our  approach  relies  on  Self-Cleansing  Intrusion  Tolerance  (SCIT), 
a  recovery- based  intrusion  tolerance  architecture  combined  with  service-oriented 
programming  constructs. 

1.  Introduction 

SOA  is  based  on  loosely  coupled  services.  Services  such  as  in¬ 
frastructure  and  common  services  are  atomic.  Other  services  are 
called  composite  services  because  they  are  composed  of  atomic 
services  or  even  other  composite  services.  A  service  is  designed 
with  clearly  defined  functionalities  that  other  services  and  applica¬ 
tions  can  use.  Along  with  the  functional  requirements,  a  service 
must  satisfy  non-functional  requirements,  among  which  security 
quality  is  a  crucial  one.  Indeed,  due  to  the  inherent  distributed 
nature  of  services  communicating  with  each  other  via  networks 
and  open  protocols,  security  quality  is  critical  in  SOA  in  order  to 
ensure  availability,  integrity,  and  confidentiality  of  services  and 
thus  make  them  usable.  On  the  other  hand,  since  security  attacks 
have  become  more  and  more  sophisticated,  a  system  cannot  rely 
solely  on  intrusion  prevention  and  detection  for  its  security  protec¬ 
tion.  Therefore,  intrusion  tolerance  systems  should  be  part  of  the 
solution  for  securing  computer  information  systems. 

The  challenge  of  making  a  service  resilient  is  that  it  is  bound 
to  expose  resources  via  open  interfaces  as  a  side  effect  while 
fulfilling  functional  and  business  requirements.  Each  resource  is 
likely  to  have  vulnerabilities,  and  these  together  constitute  the 
service’s  attack  surface,  which  includes  operations,  data  items 
accessible  to  read  and/or  write,  and  communication  channels 
over  which  services  operate  [1].  The  more  operations  and  data 
a  service  provides,  the  more  its  attack  surface  increases.  Thus, 
limiting  the  attack  surface  does  not  always  work.  Moreover,  if 
COTS  is  used  to  realize  a  service,  then  the  service’s  attack  sur¬ 
face  is  pretty  much  predefined,  leaving  little  room  for  reducing 
its  exposure  via  configuration. 


In  this  paper,  we  will  present  an  approach  to  build  a  resilient 
SOA  environment,  which  has  four  characteristics:  a)  to  withstand 
malicious  attacks;  b)  to  rapidly  recover  from  compromises;  c) 
to  provide  service  continuity  even  in  the  case  of  attacks;  and 
d)  to  adapt  to  changing  operational  environment.  The  char¬ 
acteristics  a)  and  b)  can  be  quantitatively  represented  by  the 
QoS  parameters  of  Mean  Time  to  Security  Failure  (MTTSF), 
and  Mean  Time  to  Repair  (MTTR)  respectively.  Our  approach 
consists  of  compensating  the  undesired  expansion  of  a  service’s 
attack  surface  due  to  enhancements  by  utilizing  Self-Cleansing 
Intrusion  Tolerance  (SCIT)  and  restricting  the  exposure  time  [2]. 
Characteristic  c)  of  service  continuity  can  be  mitigated  by  having 
redundant  live  nodes,  with  the  pair  of  primary/backup  and  diver¬ 
sity  in  the  SCIT  environment.  We  will  also  show  how  SCIT  allows 
services  to  adapt  to  changing  environment  while  maintaining 
their  promised  resilience.  Based  on  timed-recovery  mechanisms 
provided  by  SCIT,  software  architects  are  offered  additional  tools 
to  design  a  service  so  that  its  attackability  can  be  controlled,  and 
intrusion  tolerance  QoS  guaranteed  despite  the  exposed  attack 
surface.  Moreover,  our  approach  leverages  service  composition 
constructs  that  allow  fronting  an  important  service  with  another 
service  well  controlled  by  SCIT  to  reinforce  the  resilience  of  the 
service  to  be  protected. 

2.  System  Architecture 

SCIT  Mechanism 

The  goal  of  SCIT  is  to  make  applications  and  services  resilient 
in  the  face  of  malicious  attacks.  SCIT’s  recovery-based  mecha¬ 
nism  consists  of  automatic  and  periodic  cleansing  of  the  servers 
running  on  a  virtualization  layer,  which  allows  the  instantiation 
of  multiple  servers  with  possible  options  of  having  different 
guest  operating  systems  on  a  single  host  machine.  Moreover, 
the  utilization  of  virtual  machines  enables  rapid  reloading  and 
reactivation  of  the  servers.  SCIT’s  pattern  operates  on  two  major 
components  as  depicted  in  Figure  1 : 

a.  Central  Controller  managing  and  controlling  all  the  nodes  to 
be  protected.  Diversity  of  these  nodes  can  be  employed  to  further 
reduce  the  likelihood  of  malicious  exploitations.  For  example,  we 
can  have  a  group  of  web  servers,  one  running  on  Linux,  another 
on  Windows,  and  a  third  one  on  Mac  OS. 

b.  Cluster  of  nodes  providing  the  same  applications  and  ser¬ 
vices.  Managed  by  the  Central  Controller,  each  node  continuously 
goes  through  the  following  state  sequence: 

•  Live  Spare  state,  in  which  the  node  is  pristine  but  offline; 

•  Active  state  for  the  duration  Wo,  (called  exposure  window), 
where  the  node  is  online  to  serve  incoming  requests; 

•  Grace  Period  state  with  pre-configured  duration,  where  the 
node  stops  accepting  new  transaction  requests,  but  completes 
processing  of  already  queued  requests; 

•  Cleansing  state,  where  the  node  is  offline  and  undergoes  the 
full  restoration  to  a  known  pristine  state. 

Given  that  the  cleansing  time  depends  on  the  specific  service, 
we  have  obtained  the  number  of  redundant  nodes  in  a  cluster 
to  perform  the  rotation  cycle  of  duration  Wo  [2].  Figure  1  shows 
that  Node  1  is  in  Active  state,  Node  2  in  Live  Spare  state,  and 
Node  n  in  Cleansing  state. 
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Figure  1.  SCIT  Architecture  Components. 

In  terms  of  deployment,  it  is  advisable  to  host  the  Controller 
physically  separated  from  the  nodes  in  order  to  avoid  a  data 
path  between  the  nodes  and  the  Controller,  thus  eliminating 
potential  malware  propagation  to  the  Controller.  Furthermore, 
in  the  current  SCIT  pattern,  the  link  from  the  Controller  to  the 
online  node  is  unidirectional. 

The  SCIT  product  has  been  developed  by  SCIT  Labs  under  the 
direction  of  Dr.  Sood.  Experimentation  was  performed  on  the  imple¬ 
mentation  of  SCIT  and  reported  in  [3],  where  results  demonstrated 
that  the  performance  and  computing  resource  usage  impacted 
by  SCIT  is  minimal.  Recently,  SCIT  Labs  was  selected  for  a  Small 
Business  Innovation  Research  award  that  focuses  on  Scalable 
Moving  Target  Defense  based  on  SCIT  technology.  Moreover,  they 
plan  to  perform  more  tests  as  to  the  application  of  SCIT  in  various 
domains— defense,  civil,  and  commercial.  Such  tests  would  assess 
the  performance  and  the  security  of  the  implementation. 

Cleansing  Mode 

The  main  functionality  of  SCIT  is  node  cleansing,  which 
consists  of  bringing  a  node  back  to  a  pristine  state  based  on  a 
virtual  image  stored  and  maintained  in  a  safe  place.  The  virtual 
image  of  a  service  can  be  created  on  an  offline  machine  to 
ensure  its  unreachability  by  potential  hackers.  There  are  two 
cleansing  modes  to  accommodate  two  types  of  services: 

Full  cleansing  mode  is  used  for  services  with  transactional 
operations.  Usually,  those  transactions  are  short  requests  so  that 
they  can  be  implemented  as  stateless  RESTFul  web  services.  In 
this  basic  cleansing  mode,  the  nodes  will  undergo  full  erasure 
to  make  room  for  the  clean  image.  This  image  is  static  because 
it  does  not  contain  any  in-flight  data.  In  fact,  since  the  service 
operations  are  stateless,  there  is  no  need  to  capture  state  infor¬ 
mation  of  the  node  before  performing  the  cleansing. 

Partial  cleansing  mode  is  used  for  services  with  long  running 
operations.  Scientific  computation  falls  into  this  category.  Since 
state  information  may  exist  when  a  node  enters  the  cleansing 
phase,  using  full  cleansing  mode  may  unintentionally  cause  loss 
of  process  state  information,  hence  corrupting  the  on-going  com¬ 
putation.  This  partial  cleansing  mode  includes  the  following  steps: 

•  Step  1 .  Capture  the  state  of  the  service  running  in  the  node 
running  the  virtual  machine,  and  create  a  snapshot  dynamic  im¬ 
age.  The  running  state  of  the  service  is  comprised  of  resources 


such  as  memory,  file  descriptors,  buffer  content,  program 
counter,  stack  pointers,  registers,  etc.  used  by  the  service  in 
the  virtual  machine.  There  has  been  research  done  in  this  area. 
Aroma  [4]  is  a  Java  compatible  VM  allowing  the  capture  of  state 
and  threads.  “Process  Introspection”  was  proposed  by  Ferrari  to 
capture  process  state  and  perform  its  recovery  [5]. 

•  Step  2.  Perform  cleansing. 

•  Step  3.  Migrate  the  snapshot  containing  the  service’s  state 
to  the  node  scheduled  to  be  turned  online. 

3.  Resilient  Service  Design 

In  this  section,  we  will  analyze  the  relationship  between  SCIT 
exposure  window  and  the  resilience  of  services  expressed  by 
the  QoS  parameters  MTTSF  (Mean  Time  To  Security  Failure) 
and  MTTR  (Mean  Time  To  Repair),  via  the  methodology  present¬ 
ed  in  [6].  The  analysis  utilizes  Semi-Markov  Chain  whose  states 
capture  the  behaviors  of  both  the  attacker  and  the  service  being 
studied.  As  a  result  of  the  established  correlation,  designing  a 
service’s  resilience  is  tantamount  to  computing  the  exposure 
window  and  the  number  of  diverse  and  redundant  services. 

To  confirm  this  theoretically  proven  mechanism  of  improving 
resilience  QoS  parameters  of  MTTSF  and  MTTR,  testing  will  be 
performed  in  addition  to  the  experiments  reported  in  [3]. 

Atomic  Service 

First,  we  start  with  an  atomic  service,  i.e.  one  that  does  not 
need  to  depend  on  other  services  in  the  SOA  framework. 

Figure  2  shows  that  service  S  protected  by  SCIT  undergoes 
three  states:  Good  (G),  Attacked  (A),  and  Failure  (F).  An  atomic 
service  starts  with  state  G.  In  the  case  where  the  service  is 
attacked  by  some  malicious  actor,  it  transitions  to  state  A  with 
attack  probability  PA.  Service  S  enters  state  F  when  it  is  com¬ 
promised.  Thanks  to  the  SCIT  periodic  cleansing  and  recovery 
scheme,  service  S  can  recover  to  good  state  G  from  state  A, 
with  probability  Pc.  Similarly,  service  S  can  get  out  of  state  F  to 
go  to  state  G  because  of  SCIT  forced  cleansing. 


Figure  2.  SCIT  Atomic  Service  Transition  Diagram. 


PA  is  factored  by  the  service’s  attack  surface  and  attack  ar¬ 
rival.  In  [2],  we  have  proved  that  the  attack  arrival  and  Pc  can  be 
controlled  by  exposure  window  W.  Since  MTTSF  and  MTTR  are 
conditioned  by  PA  and  Pc,  it  can  be  shown  that  MTTSF  increases 
and  MTTR  decreases  when  W  decreases. 

Orchestration  with  Dependent  Services 

The  notion  of  attack  target  and  enabler  is  described  in  [7]; 
malicious  intruders  can  exploit  the  enabler’s  attack  surface  to 
get  access  to  and  compromise  the  aimed  target.  With  the  SOA 
paradigm,  we  can  have  a  service  orchestration  with  enabler 
services  and  a  target  service.  For  example,  let  us  consider  the 
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case  of  an  archive  application  that  allows  a  public  user  to  search 
for  digital  records  preserved  in  the  archive.  The  application  is 
implemented  as  a  composition  of  User  Input  Service,  which 
validates  all  user  input  criteria  in  the  search  requests,  and  the 
Search  Service  performing  the  actual  search.  The  Search  Ser¬ 
vice  can  be  based  on  a  Free  Open  Source  Software  or  COTS, 
such  as  Apache  Solr,  SeekQuarry,  Autonomy,  Vivisimo,  Google 
Search  Appliance,  FAST,  etc.,  whose  attack  surfaces  have  been 
pre-determined  at  release  time.  The  key  characteristic  of  the 
composite  service  with  enabler  as  depicted  by  Figure  3  is  that 
an  attacker  must  compromise  the  enabler  service  SI  first  before 
she  can  break  into  the  target  service  S. 

States  G,  A,  and  F  of  enabler  service  S1  are  the  same  as  for  an 
atomic  service.  The  transition  from  state  F  to  FA  expresses  the 
notion  of  enabler  and  target  mentioned  above.  State  FF  happens 
when  both  services  are  compromised.  Our  discussion  considers 
only  one  enabler  service,  but  can  be  extended  to  the  case  where 
there  are  multiple  enablers  in  the  service  orchestration. 

Since  the  composite  service  can  transition  from  F  to  G  thanks 
to  cleansing,  we  can  make  the  following  (see  Equation  1): 


Pa  =  1  -  Pci- 

Equation  1: 

The  significance  of  this  equation  is  quite  interesting.  Indeed,  it 
reveals  that  probability  of  attack  to  the  target  can  be  controlled 
by  means  of  the  cleansing  probability  PC1  of  the  enabler  service 
Sr  Overcoming  S’s  attack  surface,  hence  improving  its  resilience 
can  be  realized  by  increasing  PC1. 

Orchestration  with  Independent  Services 

Services  S1  and  S2  are  independent  in  terms  of  attackability, 
as  shown  by  the  paths  G1— >G2— >A2  and  F1— >G2  (Figure  4). 

The  same  would  apply  for  parallel  or  conditional  branches  in  a 
service  orchestration.  Consequently,  in  order  to  analyze  these 
cases,  we  can  apply  the  results  for  an  atomic  service  to  the 
services  S1  and  S2  separately. 

Diversity 

In  the  literature,  diversity  has  been  proposed  as  one  of  the 
mechanisms  to  increase  the  resilience  of  services.  Let  {s.  | 
i=1  ,..,N}  be  the  set  of  N  different  versions  of  the  same  service 
S,  which  can  be  obtained  by  using  different  operating  sys¬ 
tems,  middleware  packages,  or  implementations  as  proposed 
by  Huang  [8].  Assuming  that  a  line  of  attack  only  works  for  a 
specific  version  of  a  service  S,  the  attack  probability  Ps  of  the 
surface  of  S  is  bounded  by  the  following  (see  Equation  2): 

1 

Ps  <  —  {  max  Ps.}, 

N  Li=i, ...n  lJ 

Equation  2: 

In  Equation  2,  the  values  PSi  are  the  attack  probabilities  of 
the  different  version  of  the  same  service  S.  This  expression 
shows  that  the  probability  of  attack  on  the  service’s  surface  will 
decrease  if  more  versions  are  used. 


4.  SCIT  and  SOA 

Service  Provider  Architecture 

For  a  single  service  provider,  the  SCIT  architecture  depicted  in 
Figure  1  is  enhanced  with  two  additional  components  (Figure  5) 
as  described  in  [9]: 

•  The  Service  Registry  contains  metadata  about  the  services  in 
the  system  including  service  operations,  access  points,  and  Intru¬ 
sion  Tolerance  QoS  (IT-QoS)  characteristics.  The  notion  of  IT-QoS 
was  introduced  in  [9]  to  capture  QoS  attributes  that  are  related  to 
an  intrusion  tolerant  system,  such  as  MTTSF,  S-Reliability,  MTTR, 
maximum  intrusion  number,  etc.  For  scientific  computation,  Com¬ 
putational  QoS  needs  to  be  considered  [10].  The  Central  Control¬ 
ler  queries  the  Service  Registry  about  desired  IT-QoS  values  for  a 
service,  and  also  updates  the  current  operational  values. 

•  The  Monitor  provides  the  Central  Controller  with  information 
about  the  current  operating  environment  based  on  analytics  of 
logs,  or  reports  provided  by  sensors  such  as  IDS  sensors. 

In  the  SOA  adaptation,  a  “node”  in  the  SCIT  architecture 
pattern  described  above  becomes  a  Service  Container,  which 
can  be  implemented  by  an  application  server  where  services  are 
deployed  and  activated.  A  Service  Container  will  host  services 
requiring  the  same  level  L  of  IT-QoS,  which  is  tied  to  a  value  for 
the  exposure  window.  In  order  to  apply  SCIT  periodic  cleansing, 
the  system  needs  N  replicas  of  similar  service  containers,  i.e. 
containers  with  services  of  same  IT-QoS  level  L.  These  N  repli¬ 
cas  form  a  Container  Group  associated  with  a  specific  level  L. 

A  system  providing  differentiated  IT-QoS  levels  will  have 
multiple  Container  Groups.  Figure  2  exhibits  an  example  of  a 
system  with  4  services  SI ,  S2,  S3  and  S4.  There  are  only  two 
levels  of  IT-QoS  denoted  by  level  1  and  level  K.  Due  to  the  low 
level  of  level  1,  Group  1  only  needs  2  replicas  of  Service  Con¬ 
tainers,  namely  Containers  1  1  and  1 2.  For  the  higher  level  K,  3 
Service  Containers  are  configured:  Containers  K1,  K2  and  K3. 
Note  that  services  SI  and  S3  are  contained  in  all  containers, 
since  they  operate  at  both  levels  1  and  K.  But,  S2  instances  are 
deployed  only  in  containers  of  level  1 ,  while  S4  instances  only  in 
containers  of  level  K. 
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5.  Conclusion 

In  this  paper,  we  have  shown  that  the  SCIT  architecture  of 
Controller,  Service  Container,  and  cleansing  algorithm  based 
on  exposure  window  contributes  to  build  a  resilient  SOA 
environment.  This  is  achieved  by  increasing  each  service’s 
resilience  in  the  SOA  ecosystem  by  compensating  the  attack 
surface  with  a  smaller  exposure  window,  reducing  the  expo¬ 
sure  window  of  Enabler  Services  in  a  service  orchestration,  or 
reducing  the  effective  attack  surface  of  a  service  with  multiple 
diverse  configurations  of  that  service.  Thanks  to  the  simple 
parameters  of  exposure  window  and  diversity  number,  software 
architects  can  specify  resilience  quality  quantitatively  during 
the  service  design.^ 


Figure  5.  SCIT  for  a  Single  Service  Provider’s  Services. 

RFFFRFMTFR 


Service  Provider  1  Service  Provider  2 


Figure  6.  Resilient  SOA  Ecosystem. 

Resilient  SOA  Ecosystem 

In  SOA,  services  can  be  provided  by  various  providers.  For 
instance,  an  application  can  utilize  storage  service  from  Ama¬ 
zon  S3,  and  incorporate  Google  map  service.  If  we  can  apply 
the  above  SCIT  resilient  architecture  to  the  service  providers 
involved  in  building  an  SOA  application,  then  we  can  create  a 
resilient  SOA  ecosystem.  Figure  6  shows  four  service  provid¬ 
ers  whose  environments  have  implemented  SCIT.  Each  service 
provider  will  have  its  own  Central  Controller  to  manage  the 
cleansing  of  its  service  containers. 
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Applying  Software 
Assurance  Concepts 
to  the  Cloud 

Randall  Brooks,  Raytheon 
John  Whited,  Raytheon 

Abstract.  It  was  once  said  that  the  last  time  one  had  full  control  of  their  software 
was  right  before  they  released  it  This  is  ever  more  important  as  organizations  move 
applications  and  services  into  a  public  cloud  to  support  a  mobile  lifestyle.  Clouds 
have  been  described  as  “a  safe  and  secure  private  cloud,”  “a  semi-trusted  partner 
cloud,”  or  “a  Wild  West  full  and  open  public  cloud.”  It  is  typically  toward  the  latter  in 
which  the  industry  has  been  moving.  Because  of  this,  developers  must  understand 
their  attack  surface  and  threat  environment  to  ensure  that  they  have  focused  on 
“building  security  into”  their  applications. 

Software  Assurance 

Software  Assurance  (SwA)  is  defined  by  the  National 
Information  Assurance  Glossary,  Committee  on  National 
Security  Systems  Instruction  (CNSSI)  No.  4009,  as  “the  level 
of  confidence  that  software  is  free  from  vulnerabilities,  either 
intentionally  designed  into  the  software  or  accidentally  inserted 
at  anytime  during  its  lifecycle,  and  that  the  software  functions  in 
the  intended  manner.”  SwA  focuses  on  “building  security  in”  to 
ensure  the  software  is  resilient  in  harsh  operating  environments 
such  as  those  in  which  cloud  applications  operate.  According  to 
the  DHS,  SwA  addresses: 

•  Trustworthiness 

•  Predictable  Execution 

•  Conformance 

In  a  cloud  environment,  Trustworthiness  is  key  to  providing 
confidence  to  the  user  that  no  exploitable  vulnerabilities  exist. 
With  use  of  mobile  and  the  cloud,  users  will  demand  Predict¬ 
able  Execution.  Cloud  applications  that  function  as  intended 
will  avoid  user  frustration.  Cloud  applications  must  conform  to 
appropriate  secure  APIs  to  ensure  interoperability  with  other 
applications  and  services. 

To  deliver  SwA,  various  principles  can  be  applied  such  as 
determining  the  criticality  of  the  application,  defining  the  Attack 
Surface,  developing  misuse  cases,  and  testing  for  unintended 
consequences.  But  these  principles  have  a  slightly  different 
emphasis  when  applied  to  the  cloud. 

Determine  Component  Risk  and  Criticality 

As  with  other  complex  problem  spaces,  understanding  Attack 
Surface,  the  threat  environment,  and  related  elements  of  risk 
management  in  the  cloud  is  best  addressed  by  first  decompos¬ 
ing  the  problem  space  into  its  constituent  components.  Stepping 
down  in  the  hierarchy  from  “the  cloud,”  we  find  the  following: 


•  A  cloud  environment  is  composed  of  interacting  systems. 

•  Each  system  may  be  comprised  of  multiple  subsystems. 

•  Systems  and  subsystems  are  built  from  one  or  more 
components  -  at  a  software  level,  the  host  OS,  most  likely  one 
or  more  guest  operating  systems,  and  the  applications  that  are 
controlled  by  the  OS  and  use  OS  services. 

This  decomposition  can  be  extended  arbitrarily  to  the 
required  depth,  until  assessing  the  risk  of  the  lowest  level  ele¬ 
ment  (here,  a  “component”)  can  be  meaningfully  addressed.  At 
this  lowest  level,  the  risk  associated  with  a  component  can  be 
characterized  by  assessing  the  following: 

•  Weaknesses  or  vulnerabilities  inherent  in  the  component 

•  The  likelihood  that  a  weakness  or  vulnerability  can  be  exploited 

•  The  existence  of  a  means  to  exploit  the  weakness 

or  vulnerability 

•  The  presence  of  a  threat  actor  with  the  skills  and  access  to 

launch  an  exploit 

•  The  impact  of  a  realized  exploit  should  it  occur 

Once  a  risk  profile  is  created  using  these  factors  for  each 
component,  a  combined  risk  analysis  can  then  be  undertaken  on 
subsystems  and  then  systems  while  considering  the  operational 
importance  to  the  organizational  mission.  This  top-down  decom¬ 
position,  component  risk  assessment,  and  bottom-up  reconstitu¬ 
tion  yields  a  structured  means  of  assessing  the  risk  associated 
with  a  complex  cloud  environment. 

Threat  Modeling:  Define  the  Attack  Surface 
and  Develop  Misuse  Cases 

To  further  understand  component  risk,  one  must  understand 
the  specific  means  by  which  a  threat  actor  might  be  able  to 
exploit  a  vulnerability.  This  is  the  component’s  Attack  Surface. 
Once  decomposition  is  accomplished,  a  good  way  to  define 
one’s  composite  Attack  Surface  is  to  perform  Threat  Modeling 
on  each  component.  Microsoft  teaches  an  application  centric 
method  called  Spoofing,  Tampering,  Repudiation,  Informa¬ 
tion  Disclosure,  Denial  of  Service,  and  Elevation  of  Privilege 
(STRIDE).  Aspects  such  as  Denial  of  Service  (DoS)  and  Eleva¬ 
tion  of  Privilege  have  a  more  pronounced  importance  in  cloud 
applications. 

For  example,  due  to  the  need  of  accessibility  to  data,  an 
effect  of  a  DoS  attack  may  cause  far  worse  consequences  in  a 
public  cloud  than  a  private  cloud.  A  prolonged  DoS  attack  may 
also  affect  user  perception  of  how  well  an  application  operates. 

Further,  if  one  hosts  their  cloud  application  with  a  cloud 
provider,  it  is  likely  that  their  application  will  reside  on  a  virtual 
machine  (VM)  running  on  a  large  server  class  system  with 
other  VMs,  as  many  public  cloud-based  systems  utilize  hosted 
VMs.  In  this  virtual  environment,  privilege  escalation  may  have 
a  far-reaching  effect  on  one’s  hosted  application  and  other  ap¬ 
plications  hosted  on  the  same  system.  As  depicted  in  Figure  1, 
a  successful  privilege  elevation  attack  of  a  hosted  VM  may  put 
other  hosted  VMs  in  one’s  “digital  neighborhood”  at  risk. 
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If  the  cloud  application  in  “App  B”  has  an  exploitable  vulner¬ 
ability,  successful  privilege  elevation  to  the  “Host  Operating 
System”,  may  enable  an  attacker  to  mediate  or  disrupt  “App  A” 
or  “App  C." 

Given  the  example  above,  threat  modeling  can  help  one  think 
about  boundaries  to  applications  and  the  various  interfaces  that 
cross  these  boundaries.  This  effort  can  help  one  derive  misuse 
cases  and  think  about  how  an  attacker  could  leverage  these 
interfaces  and  discover  flaws  in  one’s  design.  Requirements  and 
test  cases  can  then  be  developed  to  focus  on  a  cloud-based  en¬ 
vironment.  These  requirements  and  associated  test  cases  may 
highlight  bugs  in  the  form  of  weaknesses  as  listed  in  the  Com¬ 
mon  Weakness  Enumeration  (CWE),  or  in  the  form  of  exploit¬ 
able  vulnerabilities  as  listed  in  the  Common  Vulnerabilities  and 
Exposures.  These  requirements  can  be  verified  and  validated 
over  time  with  periodic  static  and  dynamic  testing. 

Static  and  Dynamic  Testing 

According  to  the  Cloud  Security  Alliance  (CSA)  Research 
group,  the  top  cloud  threats  are  “Trust,  Data  Leakage,  Insecure 
Cloud  software,  Malicious  use  of  Cloud  services,  Account/ 
Service  Hijacking,  Malicious  Insiders,  and  other  Cloud-specific 
attacks.”  Testing  one’s  cloud  application  prior  to  deployment  and 
early  within  the  System  Development  Lifecycle  is  important  to 
ensure  SwA  of  the  cloud  application. 

Static  Application  Security  Testing  (SAST)  and  Dynamic 
Application  Security  Testing  (DAST)  are  critical  activities  to 
ensuring  secure  coding  practices  are  verified  and  that  no  la¬ 
tent  vulnerability  remains.  For  DAST,  additional  focus  should  be 
applied  to  simulating  a  cloud  environment  and  to  fuzz  testing 
input  and  protocols. 

SAST  should  focus  on  the  CWEs  most  relevant  to  one’s 
mission.  With  knowledge  of  one’s  component  risk  and  critical¬ 
ity,  the  Common  Weakness  Risk  Analysis  Framework  can  be 
applied  to  prioritize  weaknesses.  For  example  a  “Use  of  a  One- 
Way  Hash  without  a  Salt  (CWE-759)”  may  be  rated  a  lower  ef¬ 
fective  risk  than  “Double  Free  (CWE-41  5).”  A  Double  Free  can 
create  corruption  that  causes  the  program  to  crash  leading  to 
service  interruption. 

DAST  should  focus  on  exercising  and  testing  the  Attack 
Surface  that  was  identified  during  threat  modeling.  Fuzz  test¬ 
ing  of  all  inputs  may  reveal  coding  weaknesses  that  represent 
exploitable  vulnerabilities.  For  example,  consider  a  “Buffer 
Copy  without  Checking  Size  of  Input  (‘Classic  Buffer  Over¬ 
flow’)  (CWE-1  20)”  that  exists  within  the  application  server.  A 
malicious  distributed  client  could  be  deployed  by  a  malevolent 
actor  to  try  multiple  concurrent  input  attempts.  Each  input 
provides  data  which  is  accepted  by  the  system,  but  which  ex¬ 
ceeds  the  expected  size  of  the  buffer  receiving  the  input.  The 
extraneous  data  can  be  crafted  to  give  control  of  the  applica¬ 
tion  to  the  attacker. 

DAST  is  particularly  useful  fortesting  backend  systems  such 
as  Databases.  One  of  the  biggest  risks  to  a  cloud  application  is 
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Figure  1.  Digital  Neighborhood 

unsanitized  input  that  is  treated  as  a  valid  database  SQL  com¬ 
mand.  The  Open  Web  Application  Security  Project  (OWASP) 
number  one  “Application  Security  Risk”  is  entitled  “A1  -  Injection”. 
OWASP  states  “Injection  flaws,  such  as  SQL,  OS,  and  Lightweight 
Directory  Access  Protocol  injection  occur  when  untrusted  data 
is  sent  to  an  interpreter  as  part  of  a  command  or  query.  The  at¬ 
tacker’s  hostile  data  can  trick  the  interpreter  into  executing  unin¬ 
tended  commands  or  accessing  unauthorized  data.”  CWE/System 
Administration,  Networking,  and  Security  Institute  Top  25  Most 
Dangerous  Software  Errors  notes  this  as  Improper  Neutralization 
of  Special  Elements  used  in  an  SQL  Command  (‘SQL  Injection’) 
(CWE-89).  DAST  can  be  leveraged  to  dynamically  execute  SQL 
commands  injected  into  the  backend  database.  This  helps  to 
locate  non-parameterized  queries  prior  to  production  release. 

Since  the  kinds  of  applications  under  discussion  will  be  in  a 
threat  environment  that  is  fully  open,  3rd  party  testing  is  more 
critical  than  ever.  Internal  development  houses  may  have  their 
“blinders”  on  and  may  lack  the  “Think  Evil”  gene  required  to  ap¬ 
propriately  test  their  application.  A  coder’s  ability  to  understand 
how  one  compromise  might  be  leveraged  to  obtain  something 
of  greater  value  may  be  lacking.  Although  education  of  software 
writers  over  time  is  important,  this  shortcoming  in  software  staff  is 
currently  prevalent  and  suggests  that  3rd  party  testing  is  a  key  to 
successful  application  security  testing  in  a  cloud  environment. 
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Figure  2.  Software  Assurance  for  the  Cloud 


Additional  Items  to  Consider 

As  shown  in  Figure  2,  the  NIST  Special  Publication  (SP)  800- 
64  Revision  2  entitled  “Security  Considerations  in  the  System 
Development  Life  Cycle”  covers  the  Initiation,  Development/ 
Acquisition,  Implementation/Assessment,  Operations  and  Main¬ 
tenance,  and  Disposal  phases  of  a  development  Life  Cycle.  The 
topics  previously  discussed  within  this  article  align  with  these 
phases,  but  can  be  further  augmented  with  training: 

•  Software  Assurance  -  Training  covering  a  general 
overview  of  SwA  and  its  importance 

•  Secure  Coding  -  Training  covering  secure  coding 
practices  to  avoid  common  programming  mistakes 

•  Certified  Secure  Software  Lifecycle  Professional 
(CSSLP)  -  A  professional  certification  by  the 
International  Information  Systems  Security 
Certification  Consortium  (ISC)2,  which  includes  eight 
Common  Body  of  Knowledge  domains 

•  Certified  Ethical  Hacker  (C|EH)  -  A  professional 
certification  provided  by  the  International  Council  of 
E-Commerce  Consultants  (EC-Council) 

•  Certificate  of  Cloud  Security  Knowledge  (CCSK)  -  A 
professional  certification  by  the  Cloud  Security  Alliance 
which  covers  14  domains  across  3  sections 

(Cloud  Architecture,  Governing  in  the  Cloud,  and 
Operating  in  the  Cloud) 


Although  not  required  when  adequate  3rd  party  security 
test  staff  is  available,  training  of  both  systems  and  software 
staff  is  important  as  it  helps  to  address  issues  early  in  the 
Life  Cycle. 

On  the  other  end  of  the  Life  Cycle  is  Operations  and  Main¬ 
tenance.  One  must  consider  the  importance  of  availability  in  a 
cloud  application.  Patching  vulnerabilities  identified  may  have 
to  take  place  while  that  system  is  online  and  operating,  which 
may  lead  to  data  integrity  and  stability  issues.  In  private  clouds 
it  may  be  permissible  to  schedule  a  maintenance  window,  and 
turn  off  portions  of  cloud  application  functionality.  In  the  highly 
dynamic  public  cloud,  where  resilience  is  key,  patching  and  op¬ 
erating  in  a  redundant  fashion  will  enable  smoother  transitions 
to  upgraded  versions. 

With  specific  reference  to  cloud  applications,  the  CSA 
publishes  the  Governance,  Risk  Management  and  Compliance 
(GRC)  stack  at  <https://cloudsecurityalliance.org/research/ 
grc-stack>.  The  GRC  stack  covers  a  suite  of  four  integrated 
initiatives:  the  Cloud  Audit,  the  Cloud  Controls  Matrix,  the 
Consensus  Assessments  Initiative,  and  the  Cloud  Trust  Protocol. 
By  applying  SwA  concepts  to  one’s  cloud  application  built  in 
compliance  with  the  GRC  stack,  one’s  application  should  be  far 
more  resilient  to  a  harsh  cloud  environment. 
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Conclusion 

It  is  important  that  organizations  understand  the  criticality 
of  their  application  or  service  with  respect  to  its  organizational 
value.  With  this  knowledge,  one  needs  to  understand  their  At¬ 
tack  Surface  and  what  affect  a  threat  may  have  to  their  critical 
program  information.  Performing  Threat  Modeling  and  focus¬ 
ing  on  architectures  can  help  one  derive  testing  requirements. 
Internal  and  external  SAST  and  DAST  testing  can  go  a  long  way 
to  ensure  SwA  of  their  cloud  application.  Always  remember  that 
the  time  spent  testing  the  application  internally  for  security  flaws 
will  be  dwarfed  by  the  time  a  determined  attacker  may  be  willing 
to  spend  attempting  to  exploit  that  application.^ 
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Cloud  Shifts  the 
Burden  of  Security 
to  Development 

Arthur  Hicken,  Parasoft 

Abstract.  The  move  to  the  cloud  brings  a  number  of  new  security  challenges, 
but  the  application  remains  your  last  line  of  defense.  Engineers  are  extremely  well 
poised  to  perform  tasks  critical  for  securing  the  application— provided  that  certain 
key  obstacles  are  overcome. 

Introduction 

This  paper  explores  three  ways  to  help  development  bear 
the  burden  of  security  that  the  cloud  places  on  them: 

•  Use  penetration  testing  results  to  help  engineers  determine 
how  to  effectively  “harden”  the  most  vulnerable  parts  of  the  ap¬ 
plication. 

•  Apply  the  emerging  practice  of  “service  virtualization”  to  pro¬ 
vide  engineers  the  test  environment  access  needed  to  exercise 
realistic  security  scenarios  from  the  development  environment. 

•  Implement  policy-driven  development  to  help  engineers 
understand  and  satisfy  management’s  security  expectations. 

New  Risks,  Same  Vulnerability 

Before  the  move  to  the  cloud,  few  organizations  lost  sleep 
over  application  security  because  they  assumed  their  internally 
controlled  security  infrastructure  provided  ample  protection.  With 
the  move  to  cloud,  security  concerns  are  thrust  into  the  forefront 
as  organizations  consider  how  much  security  control  they  are 
willing  to  relinquish  to  cloud  service  providers  and  what  level  of 
exposure  they  are  willing  to  allow  [1]. 

The  fact  of  the  matter  is  that  with  or  without  the  cloud,  failure 
to  secure  the  application  always  is— and  always  has  been— a 
dangerous  proposition  [2].  Even  when  the  bulk  of  the  network 
security  rested  under  the  organization’s  direct  control,  attackers 
still  managed  to  successfully  launch  attacks  via  the  application 
layer.  From  the  2002  breach  at  the  Australian  Taxation  office 
where  a  hacker  accessed  tax  details  on  1 7,000  businesses  [3], 
to  the  2006  incident  where  Russian  hackers  stole  credit  card 
information  from  Rhode  Island  government  systems  [4],  to  the 
recent  attack  that  brought  down  the  NIST  vulnerability  database 
[5],  it  is  clear  that  a  deficiency  in  the  application  layer  can  the  be 
one  and  only  entry  point  an  attacker  needs. 

Public  cloud,  private  cloud,  or  no  cloud  at  all,  the  application 
is  your  last  line  of  defense  and  if  you  do  not  properly  secure  the 
application,  you  are  putting  the  organization  at  risk  [6].  Nev¬ 
ertheless,  the  move  to  the  cloud  does  bring  some  significant 
changes  to  the  application  security  front: 

•  Applications  developed  under  the  assumption  of  a  bullet¬ 
proof  security  infrastructure  might  need  to  have  their  strategies 
for  authorization,  encryption,  message  exchange,  and  data  stor¬ 
age  re-envisioned  for  cloud-based  deployment. 


•  The  move  to  cloud  architectures  increases  the  attack 
surface  area,  potentially  exposing  more  entry  points  for  hackers. 
This  attack  surface  area  is  compounded  with  more  distributed 
computing  technologies,  such  as  mobile,  web,  and  APIs. 

•  As  applications  shift  from  monolithic  architectures  to 
composite  ones,  there  is  a  high  degree  of  interconnectedness 
with  3rd  party  services— and  a  poorly  engineered  or  malfunction¬ 
ing  dependency  could  raise  the  security  risk  of  all  connected 
components.  For  example,  a  recent  attack  on  Yahoo  exploited 

a  vulnerability  from  a  third-party  application  [7]  The  composite 
application  is  only  as  secure  as  its  weakest  link. 

•  As  organizations  push  more  (and  more  critical)  functional¬ 
ity  to  the  cloud,  the  potential  impact  of  an  attack  or  breach  esca¬ 
lates  from  embarrassing  to  potentially  devastating— in  terms  of 
safety,  reputation,  and  liability. 

With  the  move  to  the  cloud  placing  more  at  stake,  it  is  now 
more  critical  than  ever  to  make  application  security  a  primary 
concern.  The  industry  has  long  recognized  that  development 
can  and  should  play  a  significant  role  in  securing  the  applica¬ 
tion.  This  is  underscored  by  the  DoD’s  directive  for  certifications 
in  the  area  of  software  development  security  (e.g.,  via  CISSP) 

[8,  9].  Select  organizations  that  have  successfully  adopted  a 
secure  application  development  initiative  have  achieved  promis¬ 
ing  results  [10].  However,  such  success  stories  still  remain  the 
exception  rather  than  the  rule. 

Should  Development  Be  Responsible  for  Applica¬ 
tion  Security? 

Due  to  software  engineers’  intimate  familiarity  with  the  ap¬ 
plication’s  architecture  and  functionality,  they  are  extremely  well- 
poised  to  accomplish  the  various  tasks  required  to  safeguard 
application  security.  Yet,  a  number  of  factors  impede  engineers’ 
ability  to  shoulder  the  burden  of  security: 

•  The  organization’s  security  objectives  are  not  effectively 
communicated  to  the  development  level. 

•  For  engineers  to  determine  whether  a  particular  module 
they  developed  is  secure,  they  need  to  access  and  config¬ 
ure  dependent  resources  (e.g.,  partner  services,  mainframes, 
databases)  for  realistic  security  scenarios— and  such  access  and 
configurability  is  not  commonly  available  within  the  development 
environment. 

•  Management  often  overlooks  security  when  defining  non¬ 
functional  requirements  for  engineers  and  planning  develop¬ 
ment  schedules;  this  oversight,  paired  with  the  myopic  nature  of 
coding  new  functionality,  commonly  reduces  security  concerns 
to  an  afterthought. 

•  Security  tests  are  frequently  started  at  the  testing  phase, 
when  it  is  typically  too  late  to  make  the  necessary  critical  archi¬ 
tectural  changes. 

In  the  following  sections,  we  explore  how  strategies  related 
to  penetration  testing,  service  virtualization,  and  policy-driven 
development  can  better  prepare  engineers  to  bear  the  heavy 
burden  of  security  that  accompanies  the  shift  to  the  cloud. 

Moving  Beyond  Penetration  Testing:  Divide  and 
Conquer 

Penetration  testing  is  routinely  used  to  barrage  the  applica¬ 
tion  with  attack  scenarios  and  determine  whether  or  not  the  ap- 
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plication  can  fend  them  off.  When  a  simulated  attack  succeeds, 
you  know  for  a  fact  that  the  application  has  a  vulnerability  which 
makes  you  susceptible  to  a  particular  breed  of  attacks.  It  alerts 
you  to  real  vulnerabilities  that  can  be  exploited  by  known  attack 
patterns— essentially  sitting  ducks  in  your  applications.  When 
a  penetration  attack  succeeds,  there  is  little  need  to  discuss 
whether  it  needs  to  be  repaired.  It  is  not  a  matter  of  “if”,  but 
rather  of  “how”  and  “when.” 

The  common  reaction  to  a  reported  penetration  failure  is  to 
have  engineers  patch  the  vulnerability  as  soon  as  possible,  then 
move  on.  In  some  situations,  taking  the  path  of  least  resistance 
to  eliminating  a  particular  known  vulnerability  is  a  necessary  evil. 
However,  relying  solely  on  a  “whack  a  mole”  strategy  for  applica¬ 
tion  security  leaves  a  considerable  amount  of  valuable  informa¬ 
tion  on  the  table— information  that  could  be  critical  for  averting 
the  next  security  crisis. 

Switching  to  a  non-software  example  for  a  moment,  consider 
what  happened  when  the  U.S.  Army  realized  how  susceptible 
Humvees  were  to  roadside  bombs  in  the  early  2000s.  After  ini¬ 
tial  ad-hoc  attempts  to  improve  security  with  one-off  fixes  (such 
as  adding  sandbags  to  floorboards  and  bolting  miscellaneous 
metal  to  the  sides  of  the  vehicles),  the  Army  devised  add-on  ar¬ 
mor  kits  to  address  structural  vulnerabilities  and  deployed  them 
across  the  existing  fleet  [1  1].  In  parallel  with  this  effort,  they  also 
took  steps  to  ensure  that  additional  protection  was  built  into 
new  vehicles  that  were  requisitioned  from  that  point  forward. 

How  does  such  as  strategy  play  out  in  terms  of  software? 

The  first  step  is  recognizing  that  successful  attacks— actual  or 
simulated— are  a  valuable  weapon  in  determining  what  parts  of 
your  application  are  the  most  susceptible  to  attack.  For  example, 
if  the  penetration  tests  run  this  week  succeed  in  an  area  of  the 
application  where  penetration  tests  have  failed  before— and 
this  is  also  an  area  that  you  have  already  had  to  patch  twice  in 
response  to  actual  attacks— this  module  is  clearly  suffering  from 
some  underlying  security  issues  that  probably  will  not  be  solved 
by  yet  another  patch. 

Divide ... 

This  is  where  “divide  and  conquer”  comes  into  play.  If  you  can 
zero  in  on  your  most  vulnerable  components,  it  is  much  simpler 
for  the  engineers  tasked  with  securing  the  application  to  devise 
an  effective  attack  plan. 

The  first  task  is  to  determine  which  parts  of  the  application 
are  most  prone  to  security  attacks.  Since  penetration  testing 
is  essentially  an  “outside  in”  testing  strategy  (e.g.,  launching 
attacks  from  the  Ul  or  API  level  and  examining  the  response  for 
indications  of  success  or  failure),  this  can  be  challenging— par¬ 
ticular  if  your  penetration  tests  are  broad  rather  than  targeted.  In 
other  words,  penetration  testing  typically  tells  you  that  a  certain 
type  of  attack  succeeded,  but  fails  to  inform  where  or  how  the 
success  was  actually  achieved. 

One  way  to  better  isolate  the  precise  point  of  failure  is  to 
have  “runtime  error  detection”  monitor  the  back-end  of  the 
application  to  report  exactly  where  the  attack  succeeded. 
Another  way  is  to  use  an  emerging  test  environment  simulation 
technique  known  as  Service  Virtualization  to  effectively  isolate 
attacks  on  a  component-by-component  basis.  This  strategy  will 
be  discussed  in  more  detail  later  in  this  paper  (along  with  other 


uses  of  service  virtualization  for  application  security  purposes). 

...and  Conquer 

Once  you  have  zeroed  in  on  the  application  components 
where  you  want  to  focus  your  application  security  resources,  it 
is  time  to  conquer  those  areas  by  addressing  security  from  the 
inside  out.  Since  the  development  team  is  most  familiar  with  the 
application  internals,  these  tasks  can  and  should  fall  under  their 
purview. 

Many  organizations  are  accustomed  to  relying  on  penetration 
testing  performed  by  performance  specialists  as  their  primary 
security  strategy.  However,  as  application  security  comes  to  the 
forefront  with  the  move  the  cloud,  it  is  no  longer  conscionable  to 
assume  that  zero  successful  penetration  test  attacks  indicates  a 
secure  application.  It  is  important  to  recognize  that  there  are  two 
key  drawbacks  of  penetration  testing: 

•  It  is  reactive:  Penetration  testing  is  a  reactive  approach, 
checking  whether  the  application  resists  a  set  of  known  attack 
patterns.  As  with  anti-virus  programs,  you  are  constantly  chasing 
after  “flavor  of  the  week”  attacks  rather  than  taking  a  proactive 
approach  of  identifying  and  removing  root  causes. 

•  It  is  incomplete:  Penetration  tests  uncover  problems  only 
in  the  paths  that  the  tests  exercise.  Considering  that  even  a 
relatively  small  10,000-line  program  has  100  million  possible 
execution  paths,  the  opportunities  for  overlooked  vulnerabilities 
are  staggering. 

Fortunately,  such  drawbacks  can  be  overcome  by  having 
development  apply  two  complementary  types  of  static  analysis 
to  the  modules  that  your  penetration  tests  identify  as  being  the 
most  vulnerable  to  security  attacks. 

Flow-based  static  analysis  is  perfectly  suited  for  quickly 
exposing  security  vulnerabilities  in  large  code  bases  without 
requiring  the  definition  or  execution  of  a  single  test  case.  You 
can  hone  in  on  vulnerabilities  like  the  ones  that  your  penetration 
tests  exposed  in  this  component,  or  you  can  scour  the  com¬ 
ponent  for  a  broader  scope  of  vulnerabilities  that  might  be  of 
interest. 

Although  flow-based  static  analysis  undeniably  checks  a 
broader  swath  of  the  application  than  penetration  testing  feasi¬ 
bly  could,  it  is  important  to  realize  that  it  is  not  a  panacea.  It  too 
has  some  significant  shortcomings.  Most  notably: 

•  A  complex  application  has  a  virtually  infinite  number  of 
paths  [1 2],  but  flow-based  static  analysis  can  traverse  only  a 
finite  number  of  paths  using  a  finite  set  of  data.  As  a  result, 
flow-based  analysis  inevitably  finds  only  a  finite  number  of 
vulnerabilities. 

•  Flow-based  static  analysis  identifies  symptoms  (where  the 
vulnerability  manifests  itself)  rather  than  root  causes  (the  code 
that  creates  or  allows  the  vulnerability). 

This  is  where  pattern-based  static  analysis  comes  in. 
Pattern-based  static  analysis  exposes  root  causes  rather  than 
symptoms,  and  can  reliably  target  every  single  instance  of  that 
root  cause.  For  example,  if  you  are  relying  on  flow-based  static 
analysis  alone,  you  will  probably  find  a  few  instances  of  SQL 
Injection  vulnerabilities. . .  but  you  will  not  find  them  all.  However, 
if  you  enforce  an  input  validation  rule  through  pattern-based 
static  analysis  that  requires  wrapping  input  methods  in  valida¬ 
tion  methods— finding  and  fixing  every  instance  where  inputs  are 
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not  properly  validated— you  can  guarantee  that  SQL  Injection 
vulnerabilities  will  not  occur  because  you  no  longer  have  a  near¬ 
infinite  number  of  paths  to  search. 

Taking  Security  to  the  Next  Level  with  Service 
Virtualization 

One  emerging  trend  that  empowers  engineers  to  perform 
additional  security  verification— from  the  early  phases  of  the 
development  process  and  from  their  traditional  development 
environment— is  Service  Virtualization.  Service  virtualization  is  a 
method  to  emulate  the  behavior  of  specific  components  in  het¬ 
erogeneous  component-based  applications.  It  is  used  to  provide 
development  and  testing  teams  access  to  dependent  system 
components  that  are  needed  to  exercise  an  application  under 
test  (AUT),  but  are  unavailable  or  difficult-to-access  for  testing 
purposes.  With  the  behavior  of  the  dependent  components 
“virtualized,”  testing  can  proceed  without  having  to  access  the 
actual  live  components. 

Service  virtualization  opens  a  number  of  opportunities  for  en¬ 
abling  engineers  to  perform  earlier  and  more  effective  security 
testing. 

Begin  Security  Testing  Earlier 

As  applications  move  to  the  cloud,  tests  that  validate  the 
security  of  an  end-to-end  transaction  must  pass  through  more 
(and  more  complex)  dependencies.  Just  testing  the  security  of 
a  single  transaction  often  involves  interacting  with  dependen¬ 
cies  ranging  from  mobile  applications,  databases,  mainframes, 
3rd  party  services,  internal  services,  and  more.  The  common 
approach  to  testing  in  such  an  interconnected  environment  is 
to  delay  testing  until  all  the  necessary  resources  can  be  ac¬ 
cessed  at  a  single  point  in  time.  However,  such  complete  access 
typically  comes  late... and  sometimes  never  comes  at  all.  With 
service  virtualization  emulating  the  behavior  of  unavailable  or 
difficult-to-access  components,  security  testing  efforts  can  start 
significantly  earlier— considerably  reducing  the  cost,  effort,  and 
resources  required  to  remediate  each  vulnerability  of  weakness 
detected. 

Isolate  Where  Attacks  Succeed 

Service  virtualization  enables  testing  and  validation  to  be 
applied  at  multiple  depths  and  levels.  By  applying  validations 
and  assertions  to  the  messages  from  the  application  under  test, 
engineers  can  isolate  and  zero  in  on  specific  components.  They 
could  validate  a  service’s  response  for  any  indication  that  its  se¬ 
curity  controls  are  not  working  properly  (or  that  additional  ones 
should  be  implemented).  For  example,  they  can  determine  how 
the  exact  element  they  are  working  on  handles  an  attempted 
attack  such  as  an  SQL  injection.  This  direct  validation  provides 
significantly  more  visibility  into  the  behavior  of  a  particular 
component  than  could  be  obtained  via  the  output  of  the  larger 
integrated  system. 

Gain  Predictable,  Complete  Environment  Access 
from  the  Development  Desktop 

After  a  vulnerability  is  exposed  during  penetration  testing  (or 


in  the  field),  the  software  engineers  responsible  for  remediat¬ 
ing  the  problem  typically  spend  considerable  effort  trying  to 
reproduce  the  problematic  behavior  in  their  own  environment  so 
that  they  can  understand  it,  diagnose  the  root  cause,  then  verify 
whether  attempted  fixes  actually  resolved  the  problem. 

When  tests  are  run  vs.  a  simulated  test  environment,  engi¬ 
neers  are  able  to  rapidly  and  accurately  replicate  the  precise 
conditions  that  triggered  the  vulnerability.  They  can  then  debug 
the  problem  and  validate  their  proposed  fixes  directly  from 
their  desktop.  If  this  debugging  and  validation  involves  systems 
beyond  development’s  scope  of  control  (e.g.,  partner  services, 
databases  that  are  difficult  to  access  for  testing,  mainframes, 
etc.),  development  can  run  vs.  simulated  instances  of  these 
systems  so  access  limitations  do  not  delay  or  compromise  their 
ability  to  complete  security  remediation  tasks. 

Moreover,  the  anytime/anywhere  access  that  service  virtual¬ 
ization  provides  enables  the  development  team  to  run  continu¬ 
ous  regression  testing.  This  ensures  that  the  team  is  alerted  if 
previously  remediated  security  vulnerabilities  ever  re-surface  as 
the  code  base  evolves. 

Run  Functional  Tests  vs.  Realistic  and  Extensive 
Security  Scenarios 

With  service  virtualization,  even  team  members  who  are  not 
security  experts  can  take  their  existing  functional  tests  cases 
and  execute  them  against  a  broad  set  of  preconfigured  security 
scenarios.  Security  specialists  can  pre-configure  the  environ¬ 
ment’s  dependencies  to  emulate  different  security  scenarios 
that  would  otherwise  be  difficult  to  set  up  and  unfeasible  to  test 
against.  For  instance,  with  SSL,  you  could  configure  acceptable 
and  unacceptable  certificates.  Or,  you  could  emulate  various 
behaviors  related  to  authorization,  authentication,  and  access 
controls.  You  could  also  configure  the  dependent  system  to 
deliver  malicious  payloads.  This  provides  very  granular  control 
over  the  security  behavior  of  the  dependencies  in  your  environ¬ 
ment.  Now,  as  a  complement  to  penetration  testing,  the  team’s 
standard  functional  test  scenarios  can  then  be  run  against  these 
different  environment  configurations. 

Perform  Stateful  Security  Testing 

While  standard  penetration  testing  simulates  attacks  through 
an  API  in  a  non-stateful  manner,  service  virtualization  lets  you 
emulate  attacks  at  various  levels  of  the  system  and  at  differ¬ 
ent  points  within  a  stateful  process  (e.g.,  at  different  points  in  a 
logical  use  case  or  workflow).  This  not  only  broadens  your  test 
coverage,  but  can  also  expose  security  vulnerabilities  that  are 
manifested  only  under  a  certain  set  of  environment  conditions— 
and  that  would  not  be  apparent  with  non-stateful  penetration 
testing. 

Closing  the  Gap:  Putting  Policy  in  Place 

A  third  component  critical  to  helping  development  shoul¬ 
der  the  burden  of  security  is  “policy-driven  development.”  The 
goal  here  is  to  ensure  that  security  requirements  (and  other 
non-functional  requirements)  are  exposed  and  measured  as 
aggressively  as  functional  requirements.  Adopting  a  policy- 
driven  development  process  where  expectations  are  enforced  in 
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a  standardized  way  across  the  development  group  is  a  low- 
hanging  fruit  for  taking  the  necessary  level  of  control  over  not 
only  what  software  is  being  developed,  but  also  over  how  that 
software  is  being  developed. 

The  first  step  in  policy-driven  development  adoption  is  to 
define  what  policies  you  want  to  implement.  Policies  can  be 
formed  around  any  aspect  of  the  development  process.  To  be 
effective,  they  must  be  definable,  enforceable,  measureable  and 
auditable.  You  can  define  as  many  policies  as  necessary  to  help 
you  achieve  your  goals,  but  you  should  start  implementing  them 
on  a  small  scale.  Introduce  a  few  policies  at  a  time,  and  as  you 
become  proficient  with  those  policies,  you  can  introduce  more  in 
small  batches.  One  approach  is  to  start  with  policies  to  ensure 
that  new  code  is  built  in  a  way  that  prevents  security  weakness¬ 
es  and  vulnerabilities.  Another  common  approach  is  to  begin  by 
focusing  on  eliminating  the  highest  severity  vulnerabilities  in  the 
existing  code  base. 

Next,  train  software  engineers  on  policies.  Beyond  document¬ 
ing  the  how  and  the  why  of  your  policies,  you  also  want  to  take 
steps  to  ensure  that  the  connection  between  the  two  is  clear. 
The  absence  of  training  is  the  Number  1  reason  policies  fail.  If  a 
policy  requires  code  to  be  structured  in  a  certain  way,  the  engi¬ 
neer  may  not  immediately  see  the  potential  for  the  bug  that  the 
structure  is  intended  to  prevent.  If  the  engineer  does  not  make 
the  connection  during  this  cycle  or  even  the  next  few  cycles, 
then  the  policy  looks  more  like  a  guideline  to  him  or  her,  leading 
typically  to  an  (incorrect)  declaration  of  “false  positives.”  Thus, 
the  code  may  not  be  properly  structured  before  the  product 
goes  to  market,  and  vulnerabilities  may  surface  in  the  field.  At 
this  point,  the  implementation  of  the  policy  has  failed. 

Finally,  use  automation  to  drive  a  sustainable  process.  Auto¬ 
mating  policy  monitoring,  as  well  as  the  process  for  routinely 
notifying  engineers  of  violations,  ingrains  policies  into  the 
day-to-day  workflow.  Without  this  level  of  automation,  policies 
will  quickly  fade  and  expected  behavior  will  degrade  back  into 
recommended  rather  than  mandated  behavior.  A  centralized 
infrastructure  capable  of  managing  policies  will  go  a  long  way 
toward  realizing  the  benefits  of  policy-driven  development.  Ide¬ 
ally,  a  single  platform  that  monitors  adherence  to  multiple  types 
of  policies  and  enables  effective  implementation  will  be  in  place 
to  deliver  the  traceability  required  for  certification  and  for  audit 
purposes. 

With  such  a  policy-driven  process  in  place,  engineers  not  only 
know  what  is  expected  of  them,  but  receive  objective,  immediate 
feedback  on  whether  they  are  meeting  expectations.  ^ 
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Ln  is  the  maximum  number  of  times  a  loop  can  loop, 
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The  factorial  (!)  is  there  because  the  order  of  running  the  test  cases  counts. 


CrossTalk-September/October  2013  39 


SECURING  THE  CLOUD 


The  Active 
Shooter  System 

LTC  Phillip  G.  Burns,  U.S.  Army 

Abstract.  The  proposed  Logical  Active  Shooter  System  is  a  referential  architec¬ 
ture  that  guides  the  securing  of  data  as  DoD  migrates  to  a  Joint  Information  Envi¬ 
ronment.  The  goal  is  to  secure  critical  information  from  malicious  access  or  misuse 
that  impacts  mission  accomplishment  throughout  the  Joint  phases  of  operation. 


Introduction 

The  United  States  of  America  faces  a  challenge-cyber 
threats  to  national  interests  abound,  while  homegrown  security 
professionals  who  are  able  to  operate  effectively  in  cyberspace 
do  not.  By  all  accounts,  this  lack  of  effective  personnel  is  the 
weakest  area  in  building  and  defending  the  network.  A  study 
by  Frost  and  Sullivan  supports  this  assertion  [1].  To  add  to  this, 
many  of  today’s  cybersecurity  professionals  have  to  read  up 
on  cyber  threats,  as  many  of  them  are  digital  immigrants  and 
are  not  digital  natives.  In  contrast,  digital  natives  grew  up  with 
computers,  video  games  and  computer  graphics.  Automation  is 
second  nature  to  digital  natives. 

DoD  organizations,  such  as  U.S.  Cyber  Command  (US- 
CYBERCOM)  and  the  NSA,  must  reach  out  to  digital  natives, 
recruiting  and  molding  them  to  build,  defend  the  military  network 
and,  at  times,  hunt  for  malicious  intruders  set  on  attacking  the 
network.  Of  course,  distinctions  between  United  States  Code 
(USC)  Title  10  and  USC  Title  50  [2]-between  operations 
and  intelligence— may  constrain  how  we  build  and  defend  the 
network,  as  well  as  hunting  adversaries.  According  to  one  re¬ 
searcher,  decisions  to  execute  a  defense  against  a  cyber  attack 
are  often  measured  in  seconds  or  milliseconds  [3].  Operators 
placed  in  that  position  must  have  Title  1 0/50  authorities  and 
the  ability  to  make  decisions  locally,  to  apply  operational  effects 
necessary  to  protect  or  isolate  the  network.  This  decision  mak¬ 
ing  is  a  learned  skill  that  adds  to  the  challenge  discussed  at  the 
outset. 

As  USCYBERCOM  and  NSA  focus  on  building  the  bench  of 
cybersecurity  professionals,  measures  must  be  in  place  to  pro¬ 
tect  information  as  the  gap  decreases  between  digital  natives 
and  digital  immigrants.  Until  the  bench  is  built,  the  focus  must 
be  to  secure  data,  but  not  overly  restrict  the  DoD  users’  access 
to  data  in  a  manner  that  prevents  collaboration. 

Within  the  scope  of  this  discussion,  the  DoD  is  directing  the 
consolidation  of  disparate  data  centers  across  the  DoD  network 
to  a  select  set  of  core  data  centers.  Efforts  will  lead  to  the  inte¬ 
gration  of  the  Army’s  portion  of  the  DoD  network  with  the  Joint 
Information  Environment  (J IE)  at  Figure  1.  The  J IE  will  provide 
a  single  network  that  is  secure,  standards-based,  flexible  and 
supports  versatile  mission  sets  [4]. 

Future  Army  network  capabilities  include  chat  services  and 
software  defined  radios  that,  in  accordance  with  the  Unified 


Compliance  Framework,  will  connect  users  at  home  or  work  with 
deployed  enterprise  users.  As  Figure  1  indicates,  all  is  geared 
to  ensure  enterprise  users  have  the  “...information  they  need, 
when  they  need  it,  in  any  environment,  to  manage  the  Army 
Enterprise  and  enable  Full-Spectrum  Operations  with  our  Joint, 
Coalition,  and  Interagency  partners  [5].”  JIE  will  usher  unprec¬ 
edented  access  to  information  and  a  new  era  of  collaboration 
and  situational  awareness  that  enables  Mission  Command, 
presenting  a  formidable  foe  to  the  Nation’s  enemies,  with  the 
technology  and  a  network  to  back  up  its  teeth. 

While  JIE  will  provide  the  standards  and  the  common  envi¬ 
ronment,  the  Services  will  employ  technologies,  such  as  Host 
Based  Security  System  (HBSS),  Public  Key  Infrastructure  (PKI), 
Rights  and  Identity  Management,  to  assure  confidentiality,  integ¬ 
rity  and  availability  of  information;  however,  these  technologies 
alone  may  not  foster  a  completely  secure  environment.  The  De¬ 
ployed  Environment  and  Defense  Information  Systems  Network 
(DISN)  clouds  at  Figure  1  typify  one-to-many  user  interactions, 
which  is  hard  to  audit  but  not  impossible. 

This  article  focuses  on  logically  and  physically  securing  critical 
DoD  information  with  limited  impact  to  the  user’s  experience 
and  collaborative  efforts  to  ensure  situational  awareness  critical 
to  Mission  Command.  This  article  explores  a  “Logical  Active 
Shooter  System”  that  ensures  data  is  protected  from  uninten¬ 
tional  or  intentional  spillage.  The  system  must  support  Title 
10/50  requirements,  while  simultaneous  restricting  the  digital 
natives’  ability  to  circumvent  its  controls.  The  Bradley  Manning 
incident  (i.e.,  “Wikileaks”)  is  mentioned  as  a  use  case. 


Figure  1 .  The  Joint  Information  Environment  -  End  State 


The  Logical  Active  Shooter  System 

U.S.  Army  Mission  Command  Center  of  Excellence’s  (CoE’s) 
Requirement  Governance  Team,  in  coordination  with  U.S.  Army 
Signal  CoE’s  TRADOC  Capability  Manager  for  Global  Network 
Enterprise,  are  developing  an  operational  framework  for  a  cloud- 
based  computing  network.  Figure  2  illustrates  [6]  a  proposed 
operational  view  underpinning  the  principles  of  this  cloud-based 
computing  network.  Deployment  of  the  Logical  Active  Shooter 
System  would  occur  after  the  JIE  end  state  as  illustrated  in 
Figure  1. 


Joint  Information  Environment  -  End  State 


The  Network  is  Core  to  a  Smaller,  More 
Capable,  Better  Trained  Expeditionary  Army  I 


*  installations  as  a  Docking 
Station 

*  Modernized  From  Strategic 
Core  to  the  Tactical  Edge 

*  Single  Secure  Network 

*  Incorporate  Echelons  Above 
Army  Requirements 

*  Centralized  Management  and 
Decentralized  Execution 


*  We  Must  Train  as  We  Fight  > 

*  Deploy  Little  to  No  Notice  ® 
Anytime,  Anywhere  in 
Austere  Environments 
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Figure  2.  Cloud  Computing  Operational  View 


Security  technologies,  such  as  HBSS,  PKI,  and  Rights  and 
Identity  Management,  will  be  critical  to  the  future  network  and 
engineered  in  the  architecture  from  the  start  to  ensure  the  end 
state  of  a  “Single  Secure  Network.”  The  DoD  and  Army  cloud- 
based  computing  networks  will  leverage  the  NIST  definition  of 
cloud  computing:  “...a  model  for  enabling  ubiquitous,  conve¬ 
nient,  on-demand  network  access  to  a  shared  pool  of  configu¬ 
rable  computing  resources  (e.g.,  networks,  servers,  storage, 
applications,  and  services)  that  can  be  rapidly  provisioned  and 
released  with  minimal  management  effort  or  service  provider 
interaction  [7].”  The  NIST  definition  implies  that  anonymous 
access  to  information  is  expected;  however,  shared  concerns  of 
mission  security  requirements,  policy,  and  compliance  consid¬ 
erations  will  be  factored  into  instantiations  of  a  cloud-based 
computing  environment. 

Within  a  deployed  setting,  loss  of  data  or  spillage  of  classi¬ 
fied  material  is  a  real  concern,  and  anonymous  access  is  hard 
to  monitor.  It  takes  leadership  and  active  participation  of  users 
to  enable  an  environment  where  mission  critical  information  is 
secured  from  unauthorized  users  and  access. 

The  Bradley  Manning  incident  illustrates  the  complexity  of 
preventing  the  spillage  of  classified  material.  The  Bradley  Man¬ 
ning  incident  is  an  excellent  use  case,  as  it  serves  as  a  stark 
reminder  when  lax  involvement  and  security  posture  by  leader¬ 
ship  and  users  go  awry.  For  uninitiated  readers,  Bradley  Man¬ 
ning,  a  digital  native  who  represented  a  class  of  insider  threat 
(a  disgruntled  employee  who  displays  some  emotional  distress), 
pled  guilty  to  mishandling  classified  materials  and  uploading 
said  information  to  WikiLeaks.org  via  his  personal  laptop.  One 
researcher  noted  that  to  mitigate  situations  like  this,  “[a]n  ‘active 
shooter’-like  stance  or  posture  is  needed.  Technical  controls 
are  required  and  in  some  cases  are  implemented,  but  to  what 
degrees  of  success  are  debatable  [8].”  The  researcher  goes  on 
to  note  that,  “Involvement  of  leadership  helps  to  improve  IT  se¬ 
curity,  and  a  well-informed  IT  security  staff  helps  to  identify  and 
correct  situations  [9].”  (For  the  purpose  of  this  article,  taking  an 
“active  shooter’-like  stance  is  to  intercept  the  malicious  attacker 
while  he  or  she  is  in  the  progress  of  executing  the  attack  on  the 
network  or  information  system.  This  taking  action  can  be  via 


involvement  of  leadership/fellow  users  or  automated  enforce¬ 
ment  of  rules  and  roles.) 

Taking  an  “active  shooter’Hike  stance  alone  will  not  in  itself 
adequately  protect  the  DoD  network  and  mission  critical 
information,  because  the  distributed  and  open-access  nature 
of  cloud  computing  injects  a  level  of  risk  that  must  be  factored 
into  risk  assessments  and  technical  controls.  A  roles-  and  rules- 
based  system  is  needed  to  adjudicate  or  restrict  access.  Figure 
3  illustrates  a  recommended  capability  that  can  secure  critical 
information  and  logically  establish  an  “active  shooter”  capability. 
For  the  purpose  of  this  article,  critical  information  is  defined  as 
information  that  enables  situational  awareness  within  a  mission 
setting  that  includes  classified  or  For  Official  Use  Only  informa¬ 
tion  where  its  unintended  release  or  leakage  impacts  a  mission 
or  strategic  aims.  Information  releasable  to  the  public  is  not 
defined  as  critical  information  that  will  be  protected. 

The  first  step  is  to  adjudicate  access  based  upon  established 
roles-  and  rules-based  policies,  to  which  users  can  authenticate 
through  technology  such  as  Rights  Management  or  PKI.  The 
goal  is  to  marry  roles-  and  rules-based  access  to  the  specific 
platform  where  access  was  initially  generated.  This  would  be  a 
goal  at  end  state.  This  is  decision  point  #1  (DPI)  as  illustrated 
in  Figure  3.  If  access  to  information  enables  collaboration  in 
support  of  mission  informational  and  situational  awareness 
requirements,  then  DP2  is  enabled.  If  identity  is  not  verified, 
then  access  to  information  is  terminated.  Levels  of  access  to  in¬ 
formation  under  DP2  are  determined  by  roles-  and  rules-based 
access  requirements.  Information  can  be  in  the  form  of  voice, 
video,  and  data.  Access  to  data  files  is  time-limited  and  files  are 
automatically  shredded  to  keep  information  relevant  and  current. 
Timeframes  for  access  to  data  file  are  determined  by  the  data 
owners. 

If  the  answer  to  DPI  is  no,  then  DP3  is  enacted,  and  the 
user’s  identity  is  verified.  If  the  user’s  identity  is  verified,  then 
the  user  has  access  to  non-mission  critical  information  only; 
screenshots  of  websites  are  prohibited;  and  data  files  are  set 
to  time  out  to  ensure  information  is  relevant  and  current.  If  the 
user’s  access  under  DP3  cannot  be  verified,  then  access  to 
information  under  this  category  is  terminated. 

Figure  3.  User  Data/Chat/Voice/Video  Access 


Figure  Three:  User  Data/Chat/Voice/Video  Access 


Screenshots  of  websites  roles :  point-to-point 

prohibited;  point-to-point  association:  document 

association;  document  timeout 

timeout 
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As  Figure  3  represents  a  recommended  capability,  there  are 
several  technologies  that  can  enable  the  capability  represented 
is  Figure  3.  While  there  are  a  number  of  solutions  available,  this 
article  will  discuss  two:  1 )  Narus  N 1 0  and  2)  Adobe’s  docu¬ 
ment  security  solution. 

(For  the  purpose  of  this  article,  Narus  N 1 0  and  Adobe’s  docu¬ 
ment  security  solutions  represent  desired  characteristics  critical 
to  securing  critical  information  as  defined  above,  which  includes 
lifecycle  management  of  critical  documents.  The  narrow  scope 
of  solution  sets  supports  refinement  of  critical  characteristics 
of  the  Logical  Active  Shooter  System:  role-  and  rule-based 
access;  a  virtual  workplace  where  documents  are  shredded,  en¬ 
crypted,  and  interleaved  upon  termination  of  connection  to  the 
virtual  workplace;  supports  bandwidth  constrained  environment.) 

The  first  solution  is  the  Narus  N 1 0.  As  a  primer,  Narus  is  a 
wholly  owned  subsidiary  of  Boeing.  The  N 1 0  has  the  ability  to 
authenticate  access  and  contain  access  based  upon  roles  and 
established  rules.  Updated  information  is  continuously  ren¬ 
dered  to  the  user,  and  a  dynamic  auditing  capability  is  enabled 
to  scope  future  access  based  upon  the  informational  needs  of 
the  user.  Users  do  not  directly  access  secured  material.  Users 
request  access  to  a  particular  document  and  a  secured,  virtual 
workplace  is  created  via  a  protected  tunnel  (see  Figure  4).  This 
virtual  workplace  facilitates  tracking,  queuing,  and  securing  of 
document  requests.  In  addition,  the  Narus  N10  interfaces  with 
a  Mobile  Synchronization  Module,  with  which  users  can  access 
current  information  every  time  documents  are  introduced  to 
their  workplace. 

According  to  Narus,  the  N10  ensures  that  “[d]ocuments 
stored  in  the  repository  are  shredded,  encrypted,  and  interleaved 
with  white  noise  before  being  scattered  randomly  throughout 
the  storage  environment  [10].”  Narus  further  touts  that  uploaded 
documents  cease  to  exist  in  any  “integral  form”  and,  therefore, 
present  no  target  for  hackers  to  attack  [11]. 

The  second  solution  is  Adobe’s  suite  of  document  security 
software.  Adobe’s  document  security  solutions  support  data 
encryption  with  symmetric,  asymmetric,  or  hybrid  keys,  in  order 
to  ensure  confidentiality.  Adobe’s  solution  supports  IT  security 


professionals  or  system  administrators  to  set  permissions,  as 
well  as  support  dynamic  document  control,  expiration,  and  digital 
signatures.  Adobe’s  document  security  product  line  includes 
Adobe  Acrobat  Family,  Adobe  Reader,  Adobe  LiveCycle  Reader 
Extensions,  Adobe  LiveCycle  Digital  Signatures,  and  Adobe 
LiveCycle  Rights  Management  [1 2].  Because  Adobe  supports 
integration  with  Lightweight  Directory  Access  Protocol  and  Ac¬ 
tive  Directory,  roles-  and  rules-based  access  control  is  possible. 

While  Adobe  can  secure  information  in  accordance  with 
Figure  3,  its  products  only  secure  the  .pdf  file  type,  and  not  the 
full  breadth  of  file  types  in  use  across  the  DoD  enterprise.  In 
contrast,  Narus  N 1 0  supports  more  of  the  file  types  found  on 
the  DoD  Enterprise.  Narus  N10  may  also  have  application  in 
securing  sensitive  information  on  strategic  networks;  however, 
before  use  in  a  tactical  setting,  it  must  first  be  evaluated,  as 
tactical  users  often  access  information  within  a  bandwidth  con¬ 
strained  environment. 

While  one  goal  of  the  J I E  is  to  eventually  virtualize  Joint 
common  services,  tactical  users  must  have  access  to  critical 
information  even  while  not  connected  to  the  DISN.  Therefore, 
developing  and  maintaining  a  common  operating  picture  in  a 
disconnected  environment  is  critical  to  the  Warfighter  and  the 
Commander  on  the  ground.  Situational  awareness  data  and 
collaborative  services  in  support  of  missions  must  go  unfettered 
throughout  the  Joint  phases  of  the  operation.  Selected  capabili¬ 
ties  must  support  this  critical  need  in  addition  to  securing  critical 
information  from  malicious  exfiltration  or  willful  disclosure  of 
critical  information. 

In  consideration  of  the  Narus  and  Adobe  capabilities,  ac¬ 
cess  validation  through  Rights  Management,  PKI,  and  Active 
Directory  is  a  critical  enabler  to  DPI .  DP2  is  divided  into  two 
sequels:  DP2-A  and  DP2-B.  DP2-A  supports  users  in  a  band¬ 
width  constrained  environment,  or  users  who  will  be  adversely 
impacted  if  disconnected  from  the  DISN.  Therefore,  DP2-A 
provides  access  to  mission  critical  information  with  point-to- 
point  association  and  document  timeout  to  ensure  information  is 
current.  DP2-B  will  support  user’s  access  to  critical  information 
when  bandwidth  and  potential  disconnection  from  the  DISN  is 
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Figure  4.  Narus  N1 0 
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not  an  overarching  concern.  DP2-B  provides  a  virtual  workplace 
that  facilitates  access  to  mission  critical  information,  in  a  man¬ 
ner  similar  to  the  Narus  N 1 0  capability  mention  above.  Figure 
5  provides  an  updated  view  of  the  proposed  Logical  Active 
Shooter  System. 

Conclusion 

The  two  Logical  Active  Shooter  System  solutions  described 
in  this  article  are  only  the  tip  of  the  iceberg  of  capabilities  that 
DoD  can  leverage.  They  provide  a  referential  architecture  that 
can  support  a  secure  cloud-based  network.  Both  capabilities 
can  go  far  to  mitigate  an  insider  threat  like  Bradley  Manning. 
With  the  recent  posturing  and  alleged  hacking  exploits  by  the 
Democratic  People’s  Republic  of  Korea,  the  need  to  secure  in¬ 
formation  against  all  threats  becomes  paramount  as  we  develop 
and  migrate  to  a  Joint  Information  Environment.  If  an  organiza¬ 
tion  takes  an  appropriate  “active  shooter’-like  stance,  then  the 
insider  threat  (intentional  or  unintentional)  can  be  effectively 
mitigated.  A  logical  means  of  bolstering  this  “active  shooter”  - 
like  stance  is  needed  to  secure  critical  information  and  limit 
exploitation  of  critical  information  by  insider  and  outsider  threats. 

Additional  Reading 

1.  “Demystifying  the  Title  10-Title  50  Debate:  Distinguishing 
Military  Operations,  Intelligence  Activities  &  Covert  Action”  by 
Mr.  Andru  Wall,  which  can  be  found  at  <http://harvardnsj.org/ 
wp-content/uploads/201 2/01/Vol.-3_Wall1  .pdf>.  Mr.  Wall  is 
a  former  legal  advisor  for  U.S.  Special  Operations  Command 
Central  (2007-2009).  He  provides  a  thorough  synopsis  of  the 
Secretary  of  Defense’s  unique  Title  10/50  responsibilities,  as 
they  pertain  to  unconventional  and  cyber  threats.  Within  the 
document,  Title  1 0/50  decisions  in  response  to  cyber  threats 
are  made  in  milliseconds  and  often  by  the  same  individual. 

2.  “Data  Breach  Investigations  Report  2012”  by  Verizon’s 
RISK  Team,  with  cooperation  from  the  Australian  Federal  Police, 
Dutch  National  High  Tech  Crime  Unit,  Irish  Reporting  and  Infor¬ 
mation  Security  Service,  Police  Central  e-Crime  Unit,  and  the 
United  States  Secret  Service.  It  can  be  found  at  <http://www. 
verizonenterprise.com/resources/reports/rp_data-breach-inves- 


tigations-report-201 2-ebk_en_xg.pdf>.  The  report  provides  sta¬ 
tistical  analysis  of  compromised  records,  and  provides  a  analysis 
of  cyber  threats  resulting  in  the  compromise  of  records. 

3.  “NSA:  Looking  for  a  Few  Good  Cybersecurity  Profession¬ 
als”  by  Dirk  Smith,  which  can  be  found  at  <http://www.network- 
world.com/news/201 2/1 1 1 31 2-nsa-cybersecurity-264223. 
html>.  Within  the  article,  the  reader  is  made  aware  of  a  current 
shortfall  of  20,000  cybersecurity  professionals,  with  a  pro¬ 
jected  shortfall  of  40,000.  No  concrete  date  was  given  for  the 
aforementioned  prediction.  NSA  is  attempting  to  mitigate  this 
by  partnering  with  the  Nation’s  service  academies,  colleges,  and 
universities. 
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Homeland 

Security 


The  Department  of  Homeland  Security,  Office  of  Cybersecurity  and 
Communications  (CS&C)  is  responsible  for  enhancing  the  security, 
resiliency,  and  reliability  of  the  Nation’s  cyber  and  communications 
infrastructure  and  actively  engages  the  public  and  private  sectors  as 
well  as  international  partners  to  prepare  for,  prevent,  and  respond  to 
catastrophic  incidents  that  could  degrade  or  overwhelm  these  strategic 
assets.  CS&C  is  seeking  dynamic  individuals  to  fill  critical  positions  in: 


Cyber  Incident  Response 
Cyber  Risk  and  Strategic  Analysis 
Networks  and  Systems  Engineering 
Computer  and  Electronic 
Engineering 


Digital  Forensics 
T  elecommunications 
Program  Management  and  Analysis 
Vulnerability  Detection  and 
Assessment 


To  learn  more  about  the  DHS,  Office  of  Cybersecurity  and 
Communications,  go  to  www.dhs.gov/ cybercareers.  To  apply  for  a 
vacant  position  please  go  to  www.usajobs.gov  or  visit  us  at 
www.DHS.gov. 


CALL  FOR  ARTICLES 

If  your  experience  or  research  has  produced  information  that  could  be  useful  to  others, 
Crosstalk  can  get  the  word  out  We  are  specifically  looking  for  articles  on  software- 
related  topics  to  supplement  upcoming  theme  issues.  Below  is  the  submittal  schedule  for 

three  areas  of  emphasis  we  are  looking  for: 

Mitigating  Risks  of  Counterfeit  and  Tainted  Components 

March/ April  2014  Issue 
Submission  Deadline:  Oct  10,  2013 

The  Immutable  Laws  of  Software  Development 

May/ June  2014  Issue 
Submission  Deadline:  Dec  10,  2013 

High  Maturity  Organizational  Characteristics 

July/August  2014  Issue 
Submission  Deadline:  Feb  10,  2014 

Please  follow  the  Author  Guidelines  for  Crosstalk,  available  on  the  Internet  at 
<www.crosstalkonline.org/submission-guidelines>.  We  accept  article  submissions  on 
software-related  topics  at  any  time,  along  with  Letters  to  the  Editor  and  BackTalk.  To  see 
a  list  of  themes  for  upcoming  issues  or  to  learn  more  about  the  types  of  articles  we’re 
looking  for  visit  <www.crosstalkonline.org/theme-calendar>. 
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BACKTALK 


Excuse  Me,  But  Do 
You  Have  the  Time? 


Back  in  1982,  I  was  a  SSgt  in  the  USAF, 
finishing  my  undergraduate  degree  at  the 
University  of  Central  Florida.  Because  of  my 
course  load,  I  was  spending  lots  and  lots  of 
time  in  the  computer  center  (I  was  taking 
Operating  Systems,  Compilers,  and  Assem¬ 
bly  Language  all  in  the  same  semester).  The 
media  I  used  for  programming  (punched 
cards)  cost  $0.94  for  500  cards.  If  you  were 
paranoid  (I  was)  and  wanted  a  backup  for  se¬ 
curity  (I  did),  all  you  needed  was  an  IBM  514 
Duplicator,  a  deck  of  fresh  cards,  and  about  2 
minutes  to  duplicate  500  cards.  My  electronic 
footprint  at  that  time,  was  three  decks  of 
cards  (one  for  each  class)  so  in  6  minutes,  I 
could  backup  everything  I  needed. 

However,  I  wearied  of  spending  nights  fight¬ 
ing  for  cardpunch  machines,  and  then  having 
to  wait  in  line  to  run  my  job.  I  decided  to  surge 
forward  with  new  technology.  I  bought  a  home 
computer— a  Commodore  SuperPet  9000— 
and  it  was  awesome!  It  had  not  one,  but  two 
processors— a  MOS  6502  (running  Commo¬ 
dore  OS  with  Commodore  Basic  and  a  Word 
Processing  program),  and  a  Motorola  6809 
(running  a  Waterloo  Programming  Operating 
System,  supporting  APL,  Fortran,  COBOL, 
Pascal,  Basic  and  Assembler).  It  had  a  blazing 
clock  speed  of  1  MHz.  It  was  possibly  the  most 
technologically  advanced  small  computer  for 
the  time  (31  years  ago). 


My  purchase  included  a  Hayes  300  baud 
Smartmodem,  and  a  dot-matrix  printer  for  a 
total  price  of  about  $4,000.  It  did  not  come 
with  a  floppy  disk  unit,  and  I  could  not  afford 
the  higher-priced  quad-density  Commodore 
8080,  so  I  bought  the  cheaper  Commodore 
4040  dual  disk  drive— a  single  unit  with  two 
disk  drives,  each  with  a  capacity  of  340K. 
Before  long,  I  migrated  almost  everything  I  had 
previously  done  manually  (using  my  typewriter) 
to  disk.  I  had  disks  for  each  class,  disks  with 
games,  disks  with  lists  of  my  VHS  tapes  ...  you 
get  the  idea.  I  had  around  20  disks  with  “criti¬ 
cal”  information. 

To  backup  all  of  my  “critical”  files,  it  took 
several  boxes  of  disks,  and  about  2-4 
minutes  to  copy  each  disk  separately.  As  often 
happened,  if  disk  had  a  single  bad  spot,  you 
had  to  scrap  the  entire  disk,  and  start  with 
a  new  one.  I  could  happily  spend  an  entire 
night  backing  up  20  disks.  I  tried  to  remember 
to  do  it  once  a  month,  so  a  bad  disk  would 
never  cost  me  more  than  30  days  of  lost 
work.  (I  also  learned  to  backup  school  data 
daily,  sometimes  hourly.)  Come  to  find  out,  the 
backup  took  up  quite  a  bit  of  my  time.  Some¬ 
times,  a  full  evening  per  month,  with  maybe 
an  hour  each  couple  of  days  for  important 
programs,  files,  reports,  etc. 

Over  the  intervening  years,  I  advanced  from 
floppies  to  “firmies”  (what  else  did  you  call 


those  3.5-inch  floppies  that  were  not  very 
floppy  on  the  outside?)  to  CDs,  then  USB 
drives,  and  now,  the  cloud. 

The  problem,  of  course,  is  that  as  the  capac¬ 
ity  for  backup  media  increases,  the  amount  of 
information  that  I  need  to  backup  increases. 
Every  backup  medium  I  used  eventually  be¬ 
came  totally  full  from  the  vast  amount  of  digital 
information  I  now  considered  important  to  keep 
backup  copies  of. 

But  the  cloud?  It  is  huge!  For  about  $45  a 
month,  I  can  have  up  to  one  terabyte  of  mostly- 
always-available  storage.  Is  that  too  costly? 
Several  commercial  cloud  providers  provide  five 
gigabytes  totally  free! 

Advantages?  It  is  online,  always  current, 
and  virtually  transparent  to  the  user.  Disadvan¬ 
tages?  You  have  to  be  online.  While  the  data 
synchronization  and  access  occurs  transpar¬ 
ently,  it  does  consume  some  bandwidth.  You 
have  a  5MB  file  that  you  want  to  access  and 
modify?  5MB  transfers  pretty  quickly.  You  want 
to  access  a  5GB  database?  Well,  unless  you 
have  some  mechanism  in  place  to  download 
or  modify  just  a  few  records  it  might  take  you 
1 ,000  times  as  long  to  download  and  then 
upload  a  modified  version. 

When  I  first  started  on  the  path  to  becoming 
a  computer  scientist,  way  back  at  the  University 
of  Central  Florida  in  1 974  (it  was  called  Florida 
Technological  University  back  then),  I  had  a 
class  in  data  structures  from  an  adjunct  profes¬ 
sor  who,  in  his  full-time  job,  designed  and  main¬ 
tained  large-scale  databases.  He  taught  me,  “It 
is  always  about  the  tradeoff  between  time  and 
space.”  Make  something  run  faster,  it  probably 
takes  up  more  storage.  Reduce  storage,  and 
the  application  almost  always  takes  longer  to 
execute. 

All  I  am  trying  to  say  is  that  nothing  is  free. 
Large-scale  cloud  usage  requires  increased 
access  and  file  update  time.  Do  not  plan  for 
real-time  performance  when  bandwidth  is 
congested,  the  Internet  is  down,  or  lots  of  users 
are  all  trying  to  access  really  large  cloud  files. 

By  the  way,  remember  those  punched  cards 
that  cost  about  $1  for  500  cards?  Well,  one 
card  equaled  about  1 60  bytes,  so  $1  bought 
me  80Kbytes  of  storage.  This  equates  to  about 
$1 2,500  per  gigabyte  of  storage.  Makes  the 
cloud  quite  a  bargain. 

David  A.  Cook,  Ph.D. 

Stephen  F.  Austin  State  University 
cookda@sfasu.edu 
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Crosstalk  thanks  the 
above  organizations  for 
providing  their  support. 


0,  Homeland 
_  Security 

Software  and  Supply  Chain  Assurance 


Software  and  Supply  Chain  Assurance 
are  essential  to  enabling  the  nation’s 
critical  infrastructure. 

To  ensure  the  integrity  of  that  infrastructure,  the 
software  and  the  IT  supply  chain  must  be  secure 
and  resilient. 

The  Software  and  Supply  Chain  Assurance 
Community  Resources  and  Information 
Clearinghouse  provides  corroboratively  developed 
resources.  Visit  https://buildsecurityin.us-cert.gov/ 
swa  to  learn  more  about  relevant  programs  and 
how  you  can  become  involved. 

Software  Assura 


Software  and  Supply  Chain 
Assurance  must  be  “built-in”  and 
supported  throughout  the  lifecycle. 

Visit  https://buildsecurityin.us-cert.gov/bsi  to 
learn  about  the  practices  for  developing  and 
delivering  software  to  provide  the  reguisite 
assurance.  Sign  up  to  become  a  free 
subscriber  and  receive  notices  of  updates. 

The  Department  of  Homeland  Security 
provides  the  public-private  collaboration 
framework  for  shifting  the  paradigm  to 
software  and  supply  chain  assurance. 
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